Glossaire glossary
Ce glossaire répertorie (par ordre alphabétique) les détails de tous les documents livrables de la liste de contrôle de projet.
Acceptation des parties prenantes de l’entreprise acceptance-from-business-stakeholders
L’acceptation par les parties prenantes de l’entreprise confirme qu’elles, en tant que parties prenantes clés, sont alignées sur la solution et ont donné leur approbation quant à la manière dont les exigences métier répondent aux exigences de l’analyse de rentabilité.
Tests d’acceptation acceptance-tests
Les tests d’acceptation sont effectués lorsqu’une application est prête pour la production. Ils sont réalisés dans des scénarios réels par un groupe représentant les différents types d’utilisateurs et utilisatrices finaux.
Les tests d’acceptation permettent de confirmer que :
- le projet répond aux exigences du client ;
- la solution est adaptée à l'usage ;
- les utilisateurs et utilisatrices acceptent la solution et peuvent envisager de l’utiliser ;
- le client ou la cliente accepte le projet.
Plus tôt vous planifiez et concevez vos tests d’acceptation, plus facile sera le déploiement final. Ils doivent être définis avec le client ou la cliente et votre équipe d’assurance qualité.
Bien que vous ne puissiez pas définir tous les détails dès le début du projet, les définitions initiales doivent être discutées et convenues. Les tests d’acceptation seront probablement basés sur les exigences fondamentales (fonctionnelles et performance).
Accès au système de test coordonné access-to-test-system-coordinated
Assurez-vous que tous les rôles ont reçu les niveaux d’accès au système requis.
Liste de contrôle de sécurité Adobe adobe-security-checklist
La liste de contrôle de sécurité Adobe est la liste de contrôle officielle fournie pour s’assurer qu’Adobe Experience Manager (AEM) est sécurisé lors de l’installation. Elle contient les mesures de sécurité et les étapes de vérification que vous devez suivre afin de garantir l’intégrité de votre instance.
Configuration du projet du portail d’assistance Adobe adobe-support-portal-project-set-up
Le portail d’assistance Adobe permet aux partenaires, clientes et clients de configurer l’implémentation d’AEM en tant que projet dans le portail d’assistance.
Des informations détaillées peuvent être enregistrées, par exemple sur les technologies et versions mises en œuvre. Elles assurent la transparence entre le client ou la cliente et Adobe.
Formation des administrateurs et administratrices AEM aem-administrator-training
Formation à la solution pour le personnel administratif. Pour plus d’informations, consultez les services de formation Adobe.
Formation de création AEM aem-author-training
Formation destinée au personnel qui produira (créera) du contenu pour la solution. Pour plus d’informations, consultez les services de formation Adobe.
Examen de certification AEM aem-certification-exam
Assurez-vous que les personnes appropriées sont enregistrées pour passer les examens de certification pertinents.
Certifié(e) AEM aem-certified
Assurez-vous que la personne appropriée a réussi les examens de certification pertinents.
Formation technique AEM aem-technical-training
Offrez une formation technique aux personnes appropriées, par exemple pour le développement, l’architecture, l’ingénierie et la pratique des affaires.
Accord sur les KPI définis comme objectifs pour le projet agreement-on-kpis-defined-as-goals-for-the-project
Les indicateurs de performances clés (KPI) aident une organisation à définir et à mesurer la progression vers ses objectifs. Une fois qu'une organisation a analysé sa mission et défini ses objectifs, elle doit mesurer les progrès vers ces objectifs. Les KPI constituent un mécanisme de mesure.
Alignement des KPI de performance et métier align-business-and-performance-kpis
L’alignement de vos KPI métier et de performance permet de rassembler toutes les personnes et tous les processus impliqués au sein de l’organisation. Cela contribue à réduire le temps et les efforts nécessaires pour atteindre les objectifs de l’entreprise et l’objectif proposé.
Alignement de l’architecture de contenu avec les KPI alignment-of-content-architecture-with-kpis
Assurez-vous que l’architecture de contenu proposée est alignée sur les indicateurs de performance clés (KPI) pertinents.
Alignement de la feuille de route cliente avec la chronologie du projet alignment-of-the-customer-roadmap-with-project-timeline
La feuille de route cliente se compose de jalons de haut niveau et d’objectifs commerciaux. La chronologie du projet doit respecter et s’aligner sur cette stratégie, de sorte que tous les risques potentiels et/ou les écarts possibles doivent être mis en évidence et suivis.
Définition de l’architecture d’application application-architecture-definition
L’architecture des applications doit définir clairement le comportement des applications proposées.
Elle est axée sur :
- la manière dont elles interagissent entre elles et avec les utilisateurs et utilisatrices ;
- les données à consommer et à produire par les applications, plutôt que leur structure interne.
Tâches de maintenance spécifiques à l’application définies application-specific-maintenance-tasks-defined
Outre les tâches de maintenance standard d’Adobe Experience Manager (AEM), vous devez définir toutes les autres tâches opérationnelles qui doivent être exécutées pour la maintenance continue de la solution.
Personnel correctement formé appropriately-trained-staff
Assurez-vous que les membres de votre équipe ont reçu une formation appropriée. Pour les équipes du projet, il est recommandé de disposer de tous les éléments suivants :
- 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 la transparence et le partage des connaissances.
Diagramme d’architecture architecture-diagram
Le diagramme d’architecture est une représentation graphique de l’architecture. Il comprend la représentation des éléments suivants :
- les concepts ;
- leurs principes ;
- les éléments et composants faisant partie de l’architecture.
Version préliminaire de l’architecture architecture-draft
Il s’agit d’une vue d’ensemble du système et de l’architecture de la solution. À ce stade, il s’agit d’une version préliminaire qui sera révisée et affinée ultérieurement.
Validation de l’ARB (Architecture Review Board) architecture-review-board-sign-off
L’ARB est un organisme interorganisationnel qui :
- supervise l’implémentation d’une stratégie cohérente ;
- assure la conformité des systèmes.
L’ARB doit être représentatif de toutes les parties prenantes clés impliquées dans l’architecture. En règle générale, il est composé d’un groupe de cadres responsables de l’examen et de la maintenance de l’architecture globale.
Suite de tests automatisés adaptée au contenu réel et aux résultats par rapport aux KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis
Scripts d’automatisation et cas d’utilisation automatisés de base :
- adaptés au contenu de production ;
- comparés aux KPI.
Stratégie de test automatisé automated-testing-strategy
Cette stratégie définit un cadre pour les scripts automatisés réutilisables, ainsi que l’approche prévue par l’équipe d’assurance qualité (QA). Elle décrit le plan général pour les tests d’automatisation afin de garantir :
- un retour sur investissement (ROI) plus élevé ;
- plus de couverture de test ;
- une fiabilité accrue des tests avec une répétition de qualité.
Stratégie de test automatisé validée par rapport à une charge réaliste et attendue automated-testing-strategy-validated-against-realistic-and-expected-load
La stratégie de test automatisé doit être validée et ajustée en fonction du contenu et de la charge attendue sur la solution.
Stratégie d’automatisation automation-strategy
L’automatisation des déploiements permet d’assurer des déploiements plus rapides et cohérents. La stratégie d’automatisation décrit la configuration de tels mécanismes d’automatisation, notamment :
- la fréquence ;
- les outils à utiliser ;
- les environnements dans lequels effectuer le déploiement.
Connaissance du plan de communication aware-of-communication-plan
L’ensemble de l’équipe du projet et toutes les parties prenantes doivent confirmer qu’elles ont connaissance des éléments suivants :
- structure des rapports ;
- fréquence des rapports ;
- canaux de communication.
Connaissance des définitions et des critères de réussite aware-of-success-definitions-and-criteria
L’ensemble de l’équipe du projet et toutes les parties prenantes doivent confirmer qu’elles ont connaissance des éléments suivants :
- définitions de la réussite ;
- critères de réussite.
Concept de sauvegarde et de restauration backup-and-restore-concept
Le concept de sauvegarde et de restauration décrit les fonctionnalités techniques qui seront implémentées dans la solution. Il est nécessaire pour la politique de sauvegarde et de restauration de l’entreprise.
Test basé sur la sauvegarde et la restauration backup-and-restore-tested
Test complet de bout en bout basé sur le concept de sauvegarde et de restauration.
Analyses de rentabilité business-case-s
Un document d’étude de cas dresse la liste des arguments relatifs à la réalisation d’une action, à la réalisation d’une autre action (si disponible) ou à l’absence d’action. Les arguments doivent être équilibrés, fondés sur des faits concrets (chaque fois que cela est possible/pertinent) et mettre en évidence les avantages et les risques pour tous les cas.
Un document d’analyse de rentabilité doit être une définition claire de toutes les options, concluant par un argument convaincant pour l’implémentation de la solution proposée.
L’analyste de la rentabilité comprend la portée du projet et les attentes business-analyst-understands-scope-of-project-and-expectations
L’analyste de la rentabilité doit comprendre parfaitement :
- la portée du projet ;
- toutes les attentes de la clientèle ;
- qu’il s’agit de la base de toutes les décisions prises par personne, par phase du projet.
KPI d’entreprise business-kpis
Les organisations utilisent des indicateurs de performances clés (IPC) pour évaluer leur capacité à atteindre des cibles.
Les KPI d’entreprise définissent des valeurs mesurables qui montrent l’efficacité avec laquelle une entreprise atteint ses principaux objectifs commerciaux. Il est important de choisir les KPI appropriés à votre entreprise/scénario et de définir clairement ce qu’ils sont, comment ils sont mesurés, comment ils sont utilisés et par qui.
Documentation des exigences de l’entreprise business-requirements-documentation
Un document des exigences de l’entreprise décrit la solution commerciale pour un projet, fournissant une spécification claire des attentes et des besoins commerciaux de la clientèle. Il fait également la distinction entre la solution commerciale et la solution technique.
Lors de l’examen de la solution d’entreprise, le document des exigences de l’entreprise doit répondre à la question suivante :
« Que souhaite faire l’entreprise ? »
Validation par l’entreprise de tout ajustement requis pour la solution ou l’architecture identifié et aligné par rapport aux attentes en matière de ROI et de KPI business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations
Les processus d’évaluation des risques et de test de pénétration peuvent générer des problèmes et des résultats qui doivent être abordés dans l’architecture ou le développement de la solution.
Les ajustements résultant de ces processus doivent être examinés et approuvés par l’entreprise, et évalués par rapport aux objectifs généraux.
Stratégie de mise en cache caching-strategy
La stratégie de mise en cache décrit les éléments qui seront mis en cache pour l’utilisateur ou l’utilisatrice finale. Elle doit être conforme aux KPI.
Par exemple, des éléments tels que des images, du code JavaScript et d’autres fichiers serveur peuvent être mis en cache pour améliorer les performances d’une solution.
Consignes de codage coding-guidelines
Les directives de codage définissent les principes de base que les développeurs et développeuses doivent respecter lors du développement de la solution. Il peut s’agir, entre autres :
- des conventions de nommage ;
- de l’utilisation du service ;
- de l’utilisation de la bibliothèque.
Communication du manuel des opérations communicate-operations-manual
Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu le manuel des opérations.
Communication du rapport de test de performances communicate-performance-test-report
Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu le rapport de test de performances.
Communication des notes de mise à jour communicate-release-notes
Assurez-vous que l’ensemble des personnes/rôles appropriés ont reçu les notes de mise à jour.
Communication de la portée et les attentes à l’équipe communicate-scope-and-expectations-to-team
Assurez-vous que l’équipe du projet est pleinement consciente de la portée du projet et des attentes en matière de diffusion, et qu’elle s’y conforme.
Communication des documents de formation et des guides d’utilisation communicate-training-materials-and-user-guides
Assurez-vous que l’ensemble des personnes/rôles appropriés reçoivent le matériel de formation et les guides d’utilisation.
Conformité aux exigences de sécurité de la clientèle compliance-with-customer-security-requirements
Assurez-vous que toutes les exigences de sécurité de la clientèle sont en place.
Conformité au concept de sécurité compliance-with-security-concept
Assurez-vous que le concept de sécurité est en place.
Concept de relation entre les composants et les modèles components-and-templates-relationship-concept
La composition des modèles et des composants utilisés dans la nouvelle application. Inclut des détails tels que les règles d’héritage, les autorisations et les relations.
Spécification de la relation entre les composants et les modèles components-and-templates-relationship-specification
Détails du concept de relation entre les composants et les modèles.
Spécification des composants components-specification
Détails des spécifications de chacun des composants à mettre en œuvre.
Concept des maquettes des interfaces externes concept-for-mock-ups-of-external-interfaces
Le concept de développement et de test des interfaces externes qui peuvent ne pas être ouvertes/disponibles pour les environnements de développement ou de test.
Planifiez/implémentez des maquettes de ces interfaces pour vous assurer que les tests sont aussi proches que possible du comportement de production.
Document d’architecture de contenu content-architecture-document
Documentation de l’architecture proposée du contenu. Les détails doivent inclure, entre autres, les éléments suivants :
- Arborescence de contenu
- Concepts de balisage
- Stratégies de réutilisation du contenu
Contenu validé pour migration content-validated-for-migration
Le contenu système hérité est examiné et le contenu sélectionné est validé pour migration vers la nouvelle solution.
Version préliminaire du contrat contract-draft
Une première version du contrat juridique.
Structure et format de contenu actuel current-content-structure-and-format
Documentation de l’architecture et du format du contenu actuel. Elle est utilisée pour générer la future architecture de contenu. Elle sert également pour le concept de migration.
Politique de sauvegarde et de restauration de la clientèle customer-backup-and-restore-policy
Politiques de la clientèle concernant les éléments suivants :
- Sauvegarde des processus pour les données et la solution
- Stockage de la sauvegarde
- Confirmation du fonctionnement de la sauvegarde
- Restauration en cas d’échec
Consignes relatives au code de la clientèle customer-coding-guidelines
Toutes les instructions/exigences de la clientèle concernant la manière dont le développement doit être effectué.
Politiques de déploiement/publication de la clientèle customer-deployment-release-policies
Politiques de la clientèle définissant comment et quand les déploiements/publications peuvent être effectués.
Il s’agit souvent de calendriers, de planifications et d’exigences de validation.
Politiques ou exigences de surveillance de la clientèle customer-monitoring-policies-or-requirements
Stratégies et exigences de la clientèle concernant les éléments à surveiller. Ces recommandations s’ajoutent aux recommandations spécifiées dans le concept de surveillance.
Calendrier des publications de production de la clientèle customer-production-release-schedule
Le planning défini par la clientèle pour les versions des environnements de production.
Politiques et exigences de création de rapports de la clientèle customer-reporting-policies-and-requirements
Toutes les politiques et/ou exigences de la clientèle concernant les rapports. Cela peut inclure :
- la fréquence à laquelle des rapports spécifiques doivent être diffusés ;
- le format de rapports spécifiques ;
- les exigences particulières.
Feuille de route de la clientèle customer-roadmap
Établissez une feuille de route des principaux jalons à mettre en œuvre, aussi bien sur le plan technologique que métier. Cette feuille de route est ensuite communiquée à la clientèle.
Politiques de sécurité de la clientèle customer-security-policies
La clientèle (entreprise et informatique) aura des politiques qui définissent les niveaux de sécurité requis pour la solution. Cela peut inclure :
- les conditions requises pour réussir une évaluation des risques ;
- les conditions requises pour réussir les tests de pénétration ;
- toutes les exigences de sécurité spécifiques, telles que l’échappement de tous les champs d’entrée, l’utilisation du chiffrement (SSL), les certificats, l’authentification et la gestion de session.
Instructions relatives aux spécifications de la clientèle customer-specification-guidelines
Toutes les directives de la clientèle relatives au format, à la diffusion et à l’approbation des spécifications.
Rapports de test de la clientèle customer-test-reports
Rapports de la clientèle à la ou au responsable qualité pendant la période de test d’acceptation utilisateur (UAT).
Personnalisations et correctifs documentés affectant les mises à niveau customizations-and-hotfixes-that-affect-upgrades-documented
Toutes les personnalisations et/ou les correctifs appliqués doivent être documentés, car ils peuvent avoir un impact sur les futures mises à niveau :
-
AEM peut être grandement personnalisé en fonction des besoins de l’entreprise. 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. Cela peut inclure :
- des packs de correctifs cumulatifs (CFP) ;
- des service packs (SP) ;
- des correctifs ;
- des mises à niveau.
Rapport de test d’acceptation utilisateur quotidien daily-user-acceptance-test-report
Rapports ou réunions résultant du test d’acceptation utilisateur (UAT). Ils doivent détailler :
- les problèmes signalés ;
- la priorisation de ces problèmes.
Sécurité par défaut activée default-security-enabled
Assurez-vous que les paramètres de sécurité par défaut d’AEM ont été activés/implémentés.
Politiques et processus de déploiement et de publication deployment-release-policies-and-processes
Politiques formalisées couvrant à la fois le déploiement et les versions de votre projet. Cela peut inclure :
- le délai des versions ;
- la planification des vacances ;
- la fréquence ;
- et peut dépendre de l’environnement en question.
Cadence de déploiement établie deployment-cadence-established
Définissez la fréquence requise des déploiements entre les environnements.
Méthodologie de développement development-methodology
Une méthodologie de développement logiciel implique de diviser l’ensemble du processus de développement logiciel en phases (ou étapes) distinctes, chacune ayant des activités distinctes. L'objectif est d’améliorer la planification et la gestion.
Lors de la définition de la méthodologie, vous devez prédéfinir des livrables et des artefacts spécifiques créés et terminés par l’équipe de projet pour développer ou gérer votre application.
Définition du rôle de développement development-role-definition
Définissez le développeur ou la développeuse et/ou le rôle qui exécute les tests informatiques (performances ou autres) et/ou unitaires dans la solution.
Environnement de développement prêt development-environment-ready
Assurez-vous que l’environnement de développement est configuré avec les outils intégrés requis pour l’automatisation des déploiements.
L’équipe de développement comprend la portée du projet et les attentes development-team-understands-scope-of-project-and-expectations
L’équipe de développement doit confirmer qu’elle comprend parfaitement :
- la portée du projet ;
- toutes les attentes de la clientèle ;
- la base de toutes les décisions prises par chaque personne, pour chaque phase dans le projet
Spécification des boîtes de dialogue dialogs-specification
Détails sur les boîtes de dialogue requises pour la solution.
Documentation de la configuration de l’environnement de développement document-development-environment-setup
Documentation de l’environnement de développement.
Documentation de la configuration de l’environnement de production document-production-environment-setup
Documentation de l’environnement de production.
Documentation de la configuration de l’environnement de test document-test-environment-setup
Documentation de l’environnement de test.
Test de durabilité durability-test
Le test de durabilité affiche les performances de la solution sous une charge spécifique. Les tests évaluent la durée de vie de la solution lorsqu’elle est soumise à la charge seuil et à quels niveaux de performances.
Test de durabilité exécuté durability-test-executed
Exécution des tests de durabilité.
Concept de gestion des erreurs error-handling-concept
La gestion des erreurs fait référence à l’anticipation, la détection et la résolution des erreurs de programmation, d’application et de communication.
Documentation de la gestion des erreurs error-handling-documentation
Documentation détaillée de la gestion des erreurs proposée, basée sur le concept de gestion des erreurs.
Processus de réaffectation escalation-processes
Définition de tous les processus de réaffectation. Il y aura des processus distincts pour chaque niveau de projet :
- Équipe du projet
- Client
- Adobe
Créer des sessions régulières d’examen de la qualité establish-regular-quality-review-sessions
Organisez régulièrement des réunions d’examen de la qualité avec les membres d’équipe concernés.
Structure d’autorisations existante existing-permissions-structure
Documentation du jeu existant d’autorisations et de groupes définis pour la solution héritée ou au sein de l’organisation.
Carte des systèmes existants existing-systems-map
Diagramme (ou ensemble de diagrammes) des systèmes et dépendances existants
Définitions et critères de réussite attendus expected-success-definitions-and-criteria
Le sponsor du projet collecte les attentes de l’entreprise associées à la réussite du projet. Il est important de disposer de l’ensemble complet des attentes au début d’un projet, car elles doivent influer sur toutes les décisions prises tout au long de la mise en œuvre.
Les attentes peuvent inclure :
- des KPI spécifiques, tels que l’augmentation en pourcentage des pages diffusées
- un temps inférieur pour la publication de contenu
- des objectifs de niveau supérieur, tels qu’une interface conviviale.
Conditions requises pour la conception d’expériences experience-designs-requirements
Conditions requises pour l’ensemble de l’expérience de la solution Cela couvre des facteurs tels que la personnalisation, la persistance entre plusieurs appareils et l’expérience utilisateur, entre autres.
Spécifications de l’expérience experience-specifications
Détails des conditions requises pour la conception de l’expérience
Système externe et dépendances des utilisateurs/contexte système external-system-and-user-dependencies-system-context
Diagramme (ou ensemble de diagrammes) décrivant l’écosystème complet de la solution Celui-ci doit inclure des éléments tels que les intégrations externes, les interfaces, les dépendances et les réseaux.
Système et procédure de secours fallback-system-and-procedure
La définition du système de secours :
- les fonctionnalités métier critiques qui doivent continuer à fonctionner en cas d’échec critique ;
- les processus requis en cas d’utilisation du système de secours ;
Système et procédure de secours testés fallback-system-and-procedure-tested
Test de bout en bout du système de secours
Validation du système de secours par les parties prenantes de l’entreprise fallback-system-sign-off-from-business-stakeholders
Validez, auprès des parties prenantes de l’entreprise, que le système de secours et les procédures associées garantissent les fonctionnalités métier essentielles.
Confirmation de faisabilité des KPI feasibility-confirmation-on-kpis
Résultats d’une étude de faisabilité pour AEM et la conception de solution de haut niveau Ces indicateurs doivent être mesurés par rapport aux KPI pour s’assurer que ceux-ci peuvent être atteints.
Contrat finalisé finalized-contract
Un contrat finalisé et signé est requis avant de poursuivre le projet. Il repose sur la Version préliminaire du contrat.
Fonctionnalité de la solution acceptée par les parties prenantes functionality-of-the-solution-accepted-by-stakeholders
Confirmation que les parties prenantes acceptent entièrement les points suivants :
- fonctionnalité de solution
- tout problème connu dans la solution
Planification de la mise en production go-live-schedule
Chronologie et planification des activités requises pour les points suivants :
- préparation à la mise en production
- la mise en production effective
Chemins propices définis happy-paths-defined
Un chemin propice est un scénario par défaut ne présentant aucune condition exceptionnelle ni aucune condition d’erreur. Il est composé de la séquence d’activités exécutée lorsque tout se passe comme prévu.
Estimations concernant le matériel hardware-estimates
Estimations initiales des points suivants :
- le matériel nécessaire à l’installation AEM de base ;
- toute exigence supplémentaire, en fonction de la conception de solution de haut niveau ;
Le matériel sera disponible pour répondre aux exigences. hardware-will-be-available-to-fulfill-requirements
Confirmation que tous les environnements bénéficieront du matériel minimum requis.
Exigences de haut niveau high-level-requirements
La définition des exigences de haut niveau fournit une répartition générale des exigences du système, couvrant des aspects tels que :
- Processus métier
- Fonctions système majeures
Les détails de base sur ces fonctions sont généralement connus. Par conséquent, ce document ne doit pas être une estimation.
Conception de solution de haut niveau high-level-solution-design
La conception de solution de haut niveau explique l’architecture utilisée pour développer la solution. Le diagramme d’architecture donne un aperçu de l’ensemble du système, identifiant les principaux composants développés pour le produit et leurs interfaces.
Carte système de haut niveau high-level-system-map
Cette carte système doit fournir un diagramme de haut niveau du système. Elle diffère du contexte de la solution, en ce sens qu’il s’agit d’une carte générale de tous les systèmes impliqués et qu’il n’y a pas d’interfaces sur ce diagramme.
Structure de contenu historique historical-content-structure
Définition de la structure de contenu du système hérité. Elle est utilisée à titre de référence et lors de la préparation de la stratégie de migration.
Performances historiques et KPI historiques historical-performance-and-historical-performance-kpis
Collectez et documentez les statistiques de performances et les KPI du système hérité. Ceux-ci sont ensuite utilisés comme point de référence et pour l’évaluation comparative de la nouvelle solution.
Identifier les solutions/fonctionnalités clés essentielles identify-critical-key-solutions-functionalities
Liste des fonctionnalités importantes d’entreprise.
Implémentation : modifications basées sur les résultats des tests de pénétration implementation-changes-based-on-penetration-test-results
Implémentation de toutes les modifications requises (qui ont été validées) de la solution en fonction des résultats des tests de pénétration.
Implémentation - Stratégie de test automatisé implementation-automated-testing-strategy
Configuration des outils et des processus requis pour la prise en charge des tests automatisés.
Implémentation - Stratégie d’automatisation implementation-automation-strategy
Configuration de l’ensemble d’outils et des processus requis pour prendre en charge l’automatisation.
Implémentation - Architecture de contenu implementation-content-architecture
Implémentation de l’architecture de contenu, des concepts de balisage et de la réutilisation du contenu.
Implémentation - Conception de l’expérience implementation-experience-design
Implémentation des exigences pour la prise en charge de la conception de l’expérience.
Implémentation - Procédures et système de secours implementation-fallback-system-and-procedures
Implémentation du système de secours et des procédures associées.
Implémentation - Intégration implementation-integration
Implémentation d’intégrations avec tous les systèmes externes requis.
Implémentation - Stratégie de migration implementation-migration-strategy
Migration et validation du contenu et d’autres artefacts pour la nouvelle solution.
Implémentation - Rôles et droits implementation-roles-and-rights
Implémentation des rôles et des droits, des utilisateurs et utilisatrices, et des groupes.
Implémentation - Concept de sécurité implementation-security-concept
Implémentation de toutes les mesures de sécurité, y compris les valeurs par défaut AEM.
Implémentation - Logiciel de sécurité implementation-security-software
Implémentation de la sécurité des applications logicielles.
Implémentation - Concept de sécurité de l’architecture système implementation-system-architecture-security-concept
Implémentation de la sécurité du système.
Implémentation- Gestion des URL implementation-url-handling
Implémentation du concept de gestion des URL.
Implémentation - Workflows implementation-workflows
Implémentation des workflows conçus.
Concept d’implémentation implementation-concept
Le concept de mise en œuvre fournit les principes directeurs de l’ensemble de la mise en œuvre. Il doit tenir compte de :
- Opérations
- Maintenance
- Compatibilité
- Réutilisation
- Sécurité
- Évolutivité
Ce concept décrit également les cadres, bibliothèques et autres artefacts utilisés dans la solution.
Informer l’assistance Adobe du calendrier d’activation inform-adobe-support-about-the-go-live-schedule
Contactez l’assistance Adobe pour vous assurer que toute assistance nécessaire pourra être mise en place pendant la mise en production.
Conceptions d’expérience initiale initial-experience-designs
Concepts préliminaires pour les conceptions des expériences.
Test d’intégration integration-testing
Tests et confirmation associée de toutes les intégrations, internes et externes.
Cette opération doit être automatisée et exécutée fréquemment pour garantir la stabilité du système.
Processus de suivi des problèmes issue-tracking-process
Des processus clairs enregistrent tous les problèmes rencontrés et effectuent le suivi des activités en cours dans le but d’assurer le traitement de tous les problèmes.
Système et processus de suivi des problèmes issue-tracking-system-and-processes
Un système de suivi, ainsi que les processus requis, pour enregistrer tous les problèmes rencontrés et suivre les activités en cours dans le but d’assurer le traitement de tous les problèmes.
Toutes les parties prenantes du projet doivent y avoir accès à pour faciliter la transparence du statut du projet.
Par exemple, Atlassian JIRA et HP Quality Center.
Le processus du système de suivi des problèmes est configuré et intégré. issue-tracking-system-process-is-set-up-and-integrated
L’outil sélectionné est entièrement intégré et l’accès est accordé à tous les rôles requis.
Système hérité legacy-system
Pour votre projet, le système hérité correspond à la technologie, au système informatique et au programme d’application existants qui seront remplacés par la nouvelle solution.
Il convient de recueillir des informations détaillées sur le système existant, afin de déterminer ce qui peut être retiré et à quel moment, ou encore quel sera l’impact sur les autres systèmes.
Liste des outils de développement à utiliser list-of-development-tools-to-be-used
Présentation des outils qui seront utilisés pour l’implémentation, notamment :
- outils de documentation
- outils de suivi des problèmes
- outils de déploiement
- outils de création
Liste des personnes ayant besoin d’un accès au portail d’assistance Adobe list-of-users-that-require-access-to-adobe-support-portal
Liste de l’ensemble des personnes et des rôles devant accéder au portail d’assistance Adobe.
La liste comprend normalement l’architecte de la solution et/ou le personnel informatique de la société cliente.
Analyse des fichiers journaux log-file-analysis
Une analyse, ainsi que les recommandations qui en résultent, définissant ce qui doit être consigné pour surveiller la solution :
- activités à consigner
- niveau de granularité
- informations consignées pour chaque activité
Tâches de maintenance (spécifiques à AEM) testées et activées maintenance-tasks-aem-specific-tested-and-enabled
Testez et activez les tâches de maintenance AEM telles que les suivantes :
- compression
- nettoyage du système
- purge des workflows
Plan de migration migration-plan
Documentation de la la migration, y compris
- chronologie de la migration
- plan de maintenance du contenu, selon la stratégie de migration
Stratégie de migration migration-strategy
Description complète du contenu, de l’architecture de contenu et des formats existants mappés à la nouvelle solution. Elle doit couvrir les éléments suivants :
- détails techniques de la migration automatisée, le cas échéant
- smoke tests à effectuer après la migration, pour valider le contenu migré
Il est également recommandé de maintenir le contenu à jour (ou le plus à jour possible) pendant la période entre la migration et la mise en production effective du nouveau système. Cela peut impliquer un gel du contenu, une double publication ou la maintenance d’un système alpha.
Surveillance - Processeur monitoring-cpu
Surveillance de l’utilisation du processeur du système par la solution :
- moyenne
- Pics
Surveillance - E/S de disque monitoring-disk-i-o
Surveillance des débits d’entrée et de sortie du disque de la solution :
- moyenne
- Pics
Surveillance - Espace disque monitoring-disk-space
Surveillance de l’utilisation de l’espace disque par la solution :
- moyenne
- croissance au fil du temps
Vous devez surveiller l’utilisation par :
- le référentiel
- les fichiers journaux
Surveillance - Systèmes externes monitoring-external-system-s
Surveillez toutes les connexions entre la solution et les systèmes externes :
- Taux de trafic
- Pics
- Stabilité
Surveillance - Bande passante réseau monitoring-network-bandwidth
Surveillez l’utilisation de la bande passante réseau de la solution :
- Taux de trafic moyen
- Pics
- Stabilité
Surveillance - Requêtes monitoring-requests
Surveillez les requêtes effectuées sur la solution.
Surveillance - Points de sécurité monitoring-security-points
Surveillez aux points de sécurité définis.
Surveillance - Système monitoring-system
Surveillez l’ensemble du système, par exemple :
- La disponibilité
- Les performances moyennes
- Les pics de performances
- Les alertes
Surveillance - Seuil et intervention monitoring-threshold-and-intervention
Surveillance du seuil défini de la solution, ainsi que mise en œuvre des étapes d’intervention pour réduire la charge.
Concept de surveillance monitoring-concept
Les concepts de surveillance à appliquer à votre solution, notamment :
- La surveillance AEM standard
- La surveillance du système
- Les exigences de surveillance spécifiques au client ou à la cliente
La surveillance des points faibles potentiels monitoring-potential-weak-points
Il convient d’identifier et de définir les points spécifiques susceptibles d’échouer. Toutes les tâches de surveillance qui y sont liées doivent également être définies.
Par exemple :
- Les workflows clés
- Le traitement des transactions
- Les points d’intégration
Politique de surveillance communiquée à l’ingénieur ou ingénieure système monitoring-policy-communicated-to-system-engineer
Assurez-vous que les ingénieurs et ingénieures système et le personnel d’exploitation connaissent et comprennent les politiques de surveillance.
Rapports de surveillance - Structure en place monitoring-reports-structure-in-place
Définissez ce qui suit :
- quand les rapports de surveillance doivent être générés ;
- à qui ils doivent être remis.
Documentation des tâches opérationnelles operational-tasks-documentation
Toutes les tâches opérationnelles documentées, avec leur fréquence définie.
Manuel des opérations operations-manual
Manuel fournissant toutes les informations requises pour le bon fonctionnement et la maintenance de la solution :
- Toutes les tâches opérationnelles
- Les contacts clés
- Les plans de déploiement
- Les listes de contrôle préalables/post-déploiement
- Toute autre tâche critique
Doit également détailler les concepts de mise en œuvre pour :
- atteindre les KPI de performance ;
- mettre à l’échelle la solution afin de continuer à atteindre ces KPI.
Package préparé package-prepared
Package logiciel créé et livré prêt pour le déploiement.
Tests de pénétration penetration-tests
Un test de pénétration (connu sous le nom informel de « pen test ») est une attaque sur un système informatique qui recherche des failles de sécurité, susceptibles d’avoir accès aux fonctionnalités et aux données de l’ordinateur.
Tests de pénétration - Réussis penetration-tests-passed
Tous les critères requis sont remplis.
Tests de pénétration - Résultats penetration-tests-results
Rapports créés pour l’entreprise expliquant les résultats des tests de pénétration.
Concept de performances et d’évolutivité performance-and-scalability-concept
Document conceptuel sur la manière de vous assurer que votre mise en œuvre réponde aux KPI de performance et de mettre à l’échelle la solution afin qu’elle continue à répondre aux exigences de ces KPI.
Référence des performances performance-benchmark
La référence des performances sert à définir les tests de performance, les tests de durabilité et la surveillance. Pour ce faire, elle évalue les caractéristiques de performance de la solution et du matériel du système.
KPI de performance performance-kpis
Ils définissent les KPI requis pour mesurer les performances du système. Voici quelques exemples : temps de chargement des pages, temps de réponse du serveur et performances des requêtes de base de données.
Tests de performance - Rapport performance-tests-report
Rapports créés pour l’entreprise, détaillant les résultats des tests de performance.
Tests de performance - Les résultats correspondent aux KPI de performance performance-tests-results-match-performance-kpis
Les résultats doivent correspondre aux KPI et aux attentes de performance définis.
Concept de test basé sur les personnes persona-based-testing-concept
Les tests basés sur les personnes sont une méthode basée sur les différentes personnes décrites dans les conceptions d’expérience. Ils testent également les comptes et leurs niveaux d’autorisations associés.
Cette méthode est souvent utilisée dans les tests d’acceptation utilisateur (UAT).
Documentation Preuve de concept (POC) testée et vérifiée par rapport aux exigences poc-tested-and-verified-against-requirement-documentation
La preuve de concept (POC) est évaluée par rapport aux exigences afin de s’assurer que toutes sont alignées.
Liste de contrôle post-déploiement post-deployment-checklist
Liste de contrôle permettant de définir la série de vérifications et de tâches à effectuer après chaque déploiement.
Liste de contrôle préalable au déploiement pre-deployment-checklist
Liste de contrôle permettant de définir la série de vérifications et de tâches à effectuer avant chaque déploiement.
Tests de performance de référence de l’environnement de production production-environment-baseline-performance-tests
Il est habituel d’exécuter un test de référence sur une installation standard d’AEM. Il est ensuite utilisé comme référence pour tester l’implémentation et le matériel.
Environnement de production prêt production-environment-ready
Vérifiez que l’environnement de production est prêt et que des déploiements automatisés sont en place.
Approbation de la production par les parties prenantes de l’entreprise production-sign-off-from-business-stakeholders
Avant l’activation sur l’environnement de production, l’approbation de production doit être accordée. Il s’agit du résultat d’une révision de la version qui sera envoyée en production, ainsi que de tous les problèmes connus. L’approbation est donnée dans le cadre du planning de mise en production.
Processus et politique d’approbation de production production-sign-off-process-and-policy
Politique et processus requis pour obtenir l’approbation de production avant de déplacer le package vers l’environnement de production.
Plan de communication du projet project-communication-plan
Définissez le plan de communication pour les parties prenantes de l’entreprise et l’équipe de projet.
Efforts du projet - Estimations finales project-efforts-final-estimates
Les estimations initiales étaient de haut niveau et établies en fonction des exigences de haut niveau de la mise en œuvre.
Elles sont maintenant révisées, affinées et améliorées afin de fournir les estimations finales. Les estimations doivent être fournies par chaque responsable de projet approprié(e), y compris la gestion de projet, le conseil, l’architecture, les tests et le développement.
Ces estimations sont utilisées pour l’approvisionnement et la budgétisation.
Efforts du projet - Estimations initiales project-efforts-initial-estimates
Les estimations initiales sont de haut niveau et établies en fonction des exigences de haut niveau pour la mise en œuvre. Ce point sera révisé et affiné ultérieurement.
Organisation du projet project-organization
La documentation requise pour décrire l’organisation et la structure des rapports du projet et de l’équipe.
Souvent, elle se présente sous la forme d’un graphique, ou en comprend un, pour présenter une vue d’ensemble visuel des calendriers et des responsabilités. De nombreux outils sont disponibles pour vous aider.
Document sur la portée du projet project-scope-document
Le document sur la portée du projet nécessite que vous identifiiez et documentiez une liste des éléments suivants :
- objectifs spécifiques au projet ;
- objectifs ;
- Fonctions
- Fonctions
- Tâches
- échéances ;
- effort prévu
Il couvre ce qui doit être accompli, ainsi que le travail à effectuer, pour mener à bien le projet.
Rapports de statut du projet dans une fréquence définie project-status-reports-within-a-defined-cadence
Les rapports de statut du projet sont remis selon le planning convenu et le format requis.
Preuve de concept (PDC) proof-of-concept-poc
La preuve de concept (POC) implémente un nombre limité de fonctions pour la solution.
Elle doit viser à démontrer la faisabilité de la solution, à vérifier qu’elle peut remplir l’objectif requis et à prouver qu’il existe un potentiel d'utilisation.
Règles de purge purge-rules
AEM conserve plusieurs versions des ressources et du contenu. Les règles de purge sont conçues et configurées pour supprimer régulièrement les anciennes versions afin de maintenir l’intégrité et la taille du référentiel.
Format et fréquence du rapport de qualité quality-report-format-and-cadence
Définissez le contenu et le format requis du rapport de qualité, ainsi que la fréquence à laquelle il doit être diffusé.
Coordination release-coordinated
Le ou la responsable de projet coordonne tous les rôles requis pour la mise en production.
Notes de mise à jour release-notes
Les notes de mise à jour font partie de la documentation de la version. Les notes de mise à jour devraient couvrir :
- 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 exécuter les étapes et les vérifications avant et après installation.
Exécution de la version dans l’environnement de production release-running-on-production-environment
Version finale en cours d’exécution et active en production.
Termes du contrat pertinents relevant-contract-terms
Mettez en évidence les termes spécifiques du contrat qui sont pertinents pour l’implémentation du projet, tels que les étapes contractuels, les périodes de facturation ou les besoins en personnel.
Fréquence des rapports reporting-cadence
Avec les clientes et clients, définissez la fréquence des rapports qui leur sont remis.
Optimisation du référentiel repository-optimization
Les données ne sont jamais écrasées dans un fichier TAR, l’utilisation du disque augmente même lors de la mise à jour des données existantes.
Pour contrer l’augmentation continue de la taille du référentiel, une stratégie d’optimisation est mise en place pour supprimer les données obsolètes.
Demande de configuration de la section du projet sur le portail d’assistance Adobe request-for-setting-up-project-section-in-adobe-support-portal
Demande officielle de configuration de votre projet sur le portail d’assistance Adobe.
Documentation requise requirements-documentation
Cet ensemble de documentation couvre les exigences fonctionnelles et non fonctionnelles, ainsi que les efforts estimés.
Ressources disponibles pour la prise en charge de la mise en production resources-available-to-support-go-live
Assurez-vous que tous les rôles requis pour la mise en production sont occupés et disponibles.
Évaluation des risques risk-assessment
L’évaluation des risques est effectuée par le service informatique et/ou le service de sécurité de la cliente ou du client.
Il évalue les risques techniques et commerciaux du projet. L’évaluation est nécessaire pour que la solution garantisse la conformité aux politiques de sécurité.
Plan d’atténuation des risques risk-mitigation-plan
Le plan d’atténuation des risques comprend l’évaluation des risques. Ensemble, ils couvrent :
- les risques identifiés ;
- des solutions possibles à ces risques s’ils surviennent dans la mise en œuvre
Attentes en matière de retour sur investissement roi-expectations
Définissez les attentes relatives au retour sur investissement (ROI) associées à la solution.
Elles visent à indiquer l’efficacité de la solution en termes économiques, en définissant les bénéfices/profits attendus par rapport à l’investissement estimé.
Concept des rôles et des droits roles-and-rights-concept
Spécification détaillée des concepts relatifs aux rôles et aux droits d’accès requis pour la nouvelle application, y compris une description détaillée des éléments suivants :
- rôles
- groupes
- d’utilisateurs ;
- autorisations ;
- et gestion et apport des utilisateurs et utilisatrices
Le concept de rôles et de droits respecte les directives de sécurité roles-and-rights-concept-meets-security-guidelines
Examinez le concept Rôles et droits pour vous assurer qu’il respecte les politiques de sécurité.
Spécification des rôles et droits roles-and-rights-specification
Spécification détaillée basée sur le concept des rôles et des droits.
Recommandations de l’architecture de sécurité security-architecture-recommendations
Recommandations liées à la sécurité pour l’architecture logicielle et matérielle.
Directives de codage basées sur la sécurité security-based-coding-guidelines
Ces directives définissent la manière dont le code de développement doit être effectué en fonction des exigences de sécurité, telles que :
- des conventions de nommage ;
- bibliothèques
- directives relatives aux frameworks
- Utilisation des API
Liste de contrôle de sécurité security-checklist
Liste de contrôle des éléments spécifiques au projet, basée sur le concept de sécurité, ainsi que toutes les politiques supplémentaires requises pour garantir la conformité de la solution.
Souvent, cela est également inclus dans les étapes de post-déploiement du runbook.
Concept de sécurité security-concept
Définissez et documentez les détails de la configuration de sécurité requis pour l’application, l’architecture et l’infrastructure.
Version préliminaire du concept de sécurité security-concept-draft
Présentation détaillée couvrant la configuration de sécurité de :
- l’application ;
- l’architecture ;
- l’infrastructure
Problèmes de sécurité répertoriés et évalués security-issues-listed-and-assessed
Tous les problèmes de sécurité de la solution répertoriés et évalués, y compris les estimations de l’effort.
Approbation de la sécurité par les parties prenantes de l’entreprise security-sign-off-from-business-stakeholders
Faites valider les parties prenantes pour vous assurer que la mise en œuvre de la sécurité est conforme aux politiques et aux attentes.
Configuration des processus de support set-up-support-processes
Définissez les processus de support requis actuellement appliqués.
SLA pour systèmes tiers slas-for-third-party-systems
Assurez-vous que les contrats de niveau de service (SLA) sont disponibles et communiqués aux équipes de développement et d’exploitation pour utilisation pendant la mise en œuvre et le support.
Concept de test de fumée smoke-test-concept
Les tests de fumée consistent en un ensemble d’étapes définies qui testent les fonctionnalités clés de la solution pour assurer les opérations et les fonctionnalités de base de la solution.
Ils sont exécutés, dans n’importe quel environnement, après installation ou déploiement.
Tests de fumée exécutés pour la validation du système smoke-tests-executed-for-system-validation
Les tests de fumée doivent être exécutés sur tous les systèmes pour garantir le bon fonctionnement des fonctionnalités de base de la solution lors de l’installation ou du déploiement dans n’importe quel environnement.
Stratégie d’architecture logicielle software-architecture-strategy
Stratégie de haut niveau pour l’architecture logicielle, y compris les services, servlets, frameworks et autres décisions d’implémentation.
Mise en place d'une commission d'examen des solutions et définition d'un calendrier de réunions solution-review-board-established-and-meeting-cadence-set
La commission d’examen des solutions est composé des parties prenantes de la clientèle.
La commission organise régulièrement des réunions pour examiner en permanence les exigences actuellement définies et les spécifications pertinentes. L’objectif est d’assurer l’alignement avec la définition et les critères de réussite et de fournir également une contribution à l’élaboration des exigences.
Manuel d’exécution de la solution solution-runbook
Instructions d’installation de la solution, ainsi que les tâches opérationnelles de base à exécuter lors de l’installation.
Processus d’approbation et d’acceptation de la solution solution-sign-off-and-acceptance-process
Le processus d’approbation et d’acceptation décrit les critères qui doivent être remplis avant que la solution ne puisse être publiée dans un environnement de production.
Il peut également servir de jalon contractuel.
Concept de fonctionnalité spéciale special-functionality-concept
Concept initial pour toute fonctionnalité spéciale qui est considérée comme ne relevant pas de la portée normale du développement sur la plateforme AEM.
Spécification des fonctionnalités spéciales special-functionality-specification
Détails de toute fonctionnalité spéciale qui est considérée comme ne relevant pas de la portée normale du développement sur la plateforme AEM.
Instructions de spécification specification-guidelines
Toutes les instructions de la clientèle sur la manière dont la spécification doit être effectuée.
Processus d’examen et d’approbation des spécifications défini et communiqué specification-review-and-approval-process-defined-and-communicated
Un processus clair doit être mis en place pour l’approbation des spécifications par la clientèle. Ce processus garantit la clarté et la fermeté de la portée des exigences.
Personnel sélectionné pour la formation des administrateurs et administratrices AEM staff-selected-for-aem-administrator-training
Personnel interne qui a besoin d’une formation pour administrer la solution.
Personnel sélectionné pour la formation de création et des utilisateurs et utilisatrices finaux staff-selected-for-author-and-end-user-training
Personnel interne qui a besoin d’une formation pour créer sur la solution.
Parties prenantes stakeholders
Les parties prenantes sont les personnes clés et/ou les rôles qui ont un intérêt important dans le projet. Certaines vont contribuer au budget du projet.
Les parties prenantes peuvent être internes et externes.
Les parties prenantes connaissent les définitions et les critères de réussite stakeholders-are-aware-of-success-definitions-and-criteria
Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont au courant des éléments suivants :
- définitions de la réussite ;
- critères de réussite.
Les parties prenantes comprennent le projet et les attentes stakeholders-understand-project-and-expectations
Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont en phase avec l’ensemble du projet et des attentes, tant au sein de l’équipe de projet que chez la clientèle.
Définition du format du rapport d’état status-report-format-definition
Les rapports d’état sont un outil de communication essentiel. Le format doit être aligné sur toutes les exigences de création de rapports de la clientèle.
Critères et définition de réussite success-criteria-and-definition
La clientèle, le sponsor du projet et la ou le responsable de projet ou la consultante ou le consultant doivent spécifier :
- Qu’est-ce qui définit un résultat positif pour le projet ?
- Les critères spécifiques requis pour répondre à cette définition de la réussite.
Ils permettent de s’assurer que les critères de réussite sont remplis :
- Comme base des KPI
- Lors de la prise de décisions tout au long de l’implémentation
Prise en charge de la validation des problèmes signalés support-in-validation-of-reported-issues
Une partie des responsabilités de la ou du responsable de la qualité consiste à s’assurer qu’il existe des ressources disponibles pour prendre en charge n’importe quel utilisateur ou utilisatrice lors des tests. Par exemple, pour aider l’utilisateur ou utilisatrice à tester, à signaler des problèmes et à valider les problèmes par rapport à l’environnement de test.
Processus d’assistance et accès au portail d’assistance Adobe support-processes-and-access-to-adobe-support-portal
L’accès au portail d’assistance Adobe est essentiel pour soumettre des tickets pour tout problème lié à un produit qui peut survenir lors de la mise en œuvre.
L’accès doit être attribué aux membres clés de l’équipe.
Définition de l’architecture du système system-architecture-definition
Une proposition initiale et une définition de l’architecture pour tous les environnements de la solution.
Documentation de l’architecture du système system-architecture-documentation
Document détaillant l’architecture du système, notamment les interfaces, l’emplacement réseau et les intégrations pour tous les environnements, entre autres informations.
Concept de sécurité de l’architecture système system-architecture-security-concept
Une description approfondie de la manière de rendre l’architecture du système compatible avec toutes les politiques de sécurité. Cela peut couvrir les éléments suivants :
- pare-feu et règles de pare-feu
- zones de sécurité
- gestionnaires de trafic locaux et généraux
- serveurs web
- proxies et proxies inverses
Facteurs de risque du système identifiés et vérifiés system-risk-factors-identified-and-verified
Tous les facteurs de risque figurant dans l’évaluation des risques (ou dans d’autres examens) sont identifiés et évalués :
- le niveau de risque implicite de chacun ;
- ainsi que l’effort estimé pour toute modification de la mise en œuvre requise pour y remédier.
L’équipe connaît les définitions et les critères de réussite. team-is-aware-of-success-definitions-and-criteria
Confirmation que l’équipe entière est au courant des définitions et des critères de réussite.
L’équipe est au courant du plan de communication. team-is-aware-of-the-communication-plan
Confirmation que tous les membres de l’équipe sont conscients de l’identité de la personne qui doit communiquer avec le client ou la cliente, ainsi que des détails sur la façon et le moment où procéder.
L’équipe comprend le projet et les attentes team-understands-project-and-expectations
Alignement avec l’ensemble du projet et des attentes, à la fois en interne avec l’équipe du projet et avec le client ou la cliente.
Exigences techniques technical-requirements
Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.
Facteurs de risque techniques vérifiés technical-risk-factors-verified
Identifiez et vérifiez les risques techniques potentiels. Les risques techniques peuvent inclure :
- script intersite
- champs de saisie destiné aux utilisateurs finaux et utilisatrices finales
- l’infrastructure
- ère technologique
- nombre d’intégrations
- et les dépendances.
Spécifications techniques technical-specification
La spécification technique couvre (entre autres informations) les éléments suivants :
- interfaces
- configurations
- API
- les services qui prennent en charge les exigences de la solution ;
Spécification du modèle template-specification
Les spécifications des modèles requis. Elles doivent couvrir les détails, notamment le parsys, le plan directeur et le mappage d’héritage.
Les spécifications sont basées sur les exigences de l’entreprise et de l’expérience.
Cas de test test-cases
Cas de test spécifiques aux étapes détaillées requises pour exécuter les tests fonctionnels de la solution.
Test du contenu test-content
Le contenu du test doit être le plus proche possible du contenu d’exploitation. Il doit comprendre une sélection suffisamment large afin de permettre de tester tous les scénarios.
Environnement de test prêt test-environment-ready
Assurez-vous que l’environnement de test est prêt, avec des déploiements automatisés pour vous assurer que tout le code du candidat de version est à jour pour les tests.
Rapports de test test-reports
Rapports détaillant les résultats des tests, notamment :
- défauts relevés
- statut des cas de test exécutés
- autres rubriques relatives à la qualité
Il convient de noter les éléments suivants :
- Toute équipe de test doit être autorisée à rester neutre et à fournir les résultats de test.
- Il incombe au chef de projet d’évaluer les implications des résultats et de décider des mesures à prendre.
Suite de tests test-suite
Sélection de la suite d’automatisation et des outils. Ils sont utilisés pour automatiser les tests, y compris ceux pour les cas d’utilisation.
Suite d’outils de test sélectionnée test-tooling-suite-selected
Suite d’automatisation et outils sélectionnés pour l’automatisation des cas d’utilisation et d’autres tâches d’exécution de test.
Concept de test testing-concept
Le concept de test est la description approfondie des tests pour le projet, y compris, l’assurance qualité, l’UAT, les performances, la sécurité et les tests d’intégration.
Plans de test testing-plans
Ces plans décrivent en détail l’exécution des tests pour chaque phase de développement et reposent sur la Stratégie de test.
Portée du test testing-scope
Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.
Stratégie de test testing-strategy
La stratégie de test décrit la stratégie approfondie pour l’assurance qualité et les tests d’acceptation utilisateur. Cela inclut les chronologies, la fréquence de création de rapports et l’exécution.
Concept d’intégration tierce third-party-integration-concept
Concept de niveau architectural et système pour l’intégration à des systèmes tiers.
Spécification d’intégration tierce third-party-integration-specification
Détails des exigences (fonctionnelles et non fonctionnelles) pour les fonctionnalités prises en charge et l’intégration des systèmes tiers.
Concept de sécurité tiers third-party-security-concept
Concept pour assurer la sécurité de toute intégration tierce. Doit être conforme aux politiques de sécurité appropriées.
Système tiers pour l’intégration third-party-system-for-integration
Assurez-vous que tous les systèmes tiers sont disponibles, avec la documentation appropriée, pour la mise en œuvre de l’intégration.
Accès aux systèmes tiers activé third-party-systems-access-enabled
Droits d’accès requis accordés aux rôles respectifs utilisés avec les systèmes tiers.
Concept de test tiers third-party-testing-concept
Définit :
- les cas d’utilisation pour tester les intégrations ;
- les fonctionnalités liées à toute application tierce
Définition du seuil threshold-definition
Définit les valeurs clés des points de surveillance dans le système.
Par exemple :
- combien de kilo-octets (Ko) de journaux non envoyés génèrent un avertissement sur l’instance de serveur principale
- le nombre de millisecondes de délai moyen par transaction toléré avant la génération d’un avertissement sur le serveur principal
Calendrier et jalons timeline-and-milestones
Cela doit définir les calendriers du projet et les jalons contractuels à utiliser pour :
- Facturation.
- Alignement par rapport aux définitions et aux critères de réussite, mais aussi aux KPI.
Total des efforts du projet total-project-efforts
Toutes les estimations de l’effort, issues de chacune des pistes du projet, doivent être consolidées, y compris les frais généraux, le développement, l’ingénierie du système, l’architecture et les efforts de test.
Si l'accord comporte un niveau de soutien, les efforts de soutien et d'exploitation devraient également être inclus.
Ressources de formation training-materials
Ressources à utiliser dans les sessions de formation. Les ressources doivent être créées spécifiquement pour la solution et conçues pour être utilisées avec les guides d’utilisation.
Comprend la portée du projet et les attentes understands-scope-of-project-and-expectations
La personne appropriée doit confirmer qu’elle comprend parfaitement les points suivants :
- la portée du projet ;
- toutes les attentes de la clientèle ;
- qu’il s’agit de la base de toutes les décisions prises par personne, par phase du projet.
Concept de gestion des URL url-handling-concept
Votre concept de gestion des URL doit couvrir les fonctionnalités d’URL spécifiques à AEM, notamment :
- URL de redirection
- externalisation des liens
- pages d’erreur
- mapping
Le concept doit également couvrir les points suivants :
- toute règle de réécriture
- hôtes virtuels sur le serveur web
- considérations relatives à la SEO, telles que robots.txt
- une carte du site
Cas d’utilisation use-cases
Un cas d’utilisation est la liste des actions ou des étapes d’événement nécessaires pour atteindre un objectif. En règle générale, il définit les interactions entre un rôle et la solution. Le rôle peut être un utilisateur, une utilisatrice ou un système externe.
Cas d’utilisation convertis en scénarios de test use-cases-converted-into-test-scenarios
Les scénarios de test sont basés sur les cas d’utilisation techniques et métier. Ils sont utilisés pour tester si le comportement de la solution est conforme aux attentes.
Guides d’utilisation user-guides
Les guides d’utilisation fournissent des informations et de l’aide aux utilisateurs et utilisatrices de la solution :
- créateurs
- personnes utilisatrices expertes
- administrateurs ou administratrices
Plan budgétaire validé validated-budget-plan
Le plan budgétaire doit être examiné et validé par toutes les parties prenantes. Celles-ci doivent vérifier les détails tels que la facturation, les montants et les méthodes/calendriers des rapports sur le budget.
Résultats des tests de boîte blanche white-box-test-results
Le test de boîte blanche est une méthode qui teste les structures ou les rouages internes d’une application, par opposition à ses fonctionnalités. Les tests de boîte blanche peuvent être appliqués au niveau de l’unité, de l’intégration et du système lors du processus de test du logiciel.
Spécifications de workflow workflow-specifications
En s’appuyant sur le concept des workflows, ces spécifications doivent définir les étapes de création du workflow complet en détail.
La spécification de chaque workflow doit inclure (au minimum) :
- cas d’utilisation
- rôles
- étapes
- résultats
- gestion des erreurs
Concept des workflows workflows-concept
Les workflows permettent d’automatiser les activités AEM. Le concept des workflows décrit :
- les processus qui nécessitent une automatisation ;
- les services et les rôles dans AEM qui seront affectés ;