Ce glossaire répertorie (de manière alpaïque) les détails de tous les documents livrables de la liste de contrôle de projet.
L’acceptation des parties prenantes professionnelles confirme que les parties prenantes principales sont alignées sur la solution et ont approuvé la manière dont les exigences de l’entreprise satisfont l’étude de cas.
Les tests d’acceptation sont réalisés lorsqu’une application est prête pour la production. Les tests sont effectués par un groupe représentant les différents types d’utilisateurs finaux, en utilisant des scénarios de la vraie vie.
Des tests d’acceptation sont utilisés pour confirmer que :
Plus tôt vous planifiez et concevez vos tests d’acceptation, plus facile sera le déploiement final. Ils devraient être définis avec le client et votre équipe d’assurance qualité.
Bien que vous ne puissiez pas définir tous les détails au tout début du projet, les définitions initiales devraient être discutées et validées. Les tests d’acceptation reposeront probablement sur les exigences de base (fonctionnelles et de performance).
Assurez-vous que les niveaux requis d’accès au système ont été accordés à tous les rôles.
La liste de contrôle de sécurité d’Adobe est la liste de contrôle officielle fournie pour assurer qu’AEM est sécurisé lors de l’installation. Elle contient les mesures de sécurité et les étapes de vérification que vous devez suivre afin de garantir l’intégrité de votre instance.
Le portail d’assistance à la clientèle Adobe permet aux partenaires et aux utilisateurs de configurer l’implémentation AEM comme un projet sur le portail d’assistance à la clientèle.
Des informations peuvent être enregistrées ; par exemple, sur les technologies et les versions mises en œuvre. Cela fournit de la transparence entre le client et Adobe.
Formation à la solution pour le personnel administratif. Voir les services de formation Adobe pour plus d’informations.
Formation pour le personnel qui produit du contenu pour la solution. Voir les services de formation Adobe pour plus d’informations.
Assurez-vous que les personnages appropriés sont inscrits pour passer les examens de certification pertinents.
Assurez-vous que les personnages appropriés ont réussi les examens de certification pertinents.
offrir une formation technique à la personne appropriée ; par exemple, les développeurs, les architectes, les ingénieurs et les professionnels.
Les indicateurs de performances clés (IPC) aident une organisation à définir et à mesurer la progression vers ses objectifs. Une fois qu’une organisation a analysé sa mission et défini ses objectifs, elle doit mesurer la progression vers ces objectifs. Les IPC fournissent un mécanisme de mesure.
L’alignement de vos indicateurs de performances clés (IPC) métier et relatifs aux performances aident à regrouper toutes les personnes et tous les processus de l’organisation. Cela permet donc de réduire la durée et les efforts nécessaires pour atteindre les objectifs métier et remplir l’objectif proposé.
Assurez-vous que l’architecture de contenu proposée est alignée sur les indicateurs de performances clés (IPC) appropriés.
La feuille de route du client se compose de jalons de haut niveau et d’objectifs métier. La chronologie du projet doit se conformer à cette stratégie et s’aligner sur celle-ci, de sorte que tous les risques potentiels et/ou déviations possibles doivent être indiqués et faire l’objet d’un suivi.
L’ architecture de l’application doit définir clairement le comportement des applications proposées.
Notamment :
Outre les tâches de maintenance standard d’Adobe Experience Manager (AEM), vous devez définir toute autre tâche opérationnelle qui doit être effectuée pour la maintenance en continu de la solution.
Assurez-vous que votre équipe se compose d’un personnel ayant reçu une formation appropriée. Pour les équipes de projet, nous recommandons chacun des éléments suivants :
Le schéma d’architecture est une représentation graphique de l’architecture. Elle inclut une représentation :
Il fournit une vue de haut niveau du système et de l’architecture de la solution. À ce stade, il s’agit d’un brouillon qui sera révisé et affiné à un stade ultérieur.
Le conseil d’examen de l’architecture est un corps trans-organisationnel qui :
Le conseil d’examen doit représenter toutes les parties prenantes principales impliquées dans l’architecture. Elles comprennent généralement un groupe de dirigeants chargés de la révision et de la maintenance de l’architecture globale.
Scripts d’automatisation et cas d’utilisation automatisés de base :
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 :
La stratégie de test automatisé doit être validée et ajustée selon le contenu et la charge attendue de la solution.
L’automatisation des déploiements assure un déploiement plus rapide et homogène. La stratégie d’automatisation décrit la configuration de tels mécanismes d’automatisation, notamment :
Toute l’équipe de projet et l’ensemble des parties prenantes doivent confirmer qu’ils ont connaissance :
Toute l’équipe de projet et l’ensemble des parties prenantes doivent confirmer qu’ils ont connaissance :
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 stratégie de sauvegarde et de restauration de l’entreprise.
Test complet de bout en bout basé sur le concept de sauvegarde et de restauration.
Un document d’étude de cas dresse la liste des arguments relatifs à la réalisation d’une action, à la réalisation d’une autre action (si disponible) ou à l’absence d’action. Les arguments doivent être équilibrés, en fonction de faits concrets (dans la mesure du possible/si approprié) et mettre en évidence à la fois les avantages et les risques pour tous les cas.
Un document d’étude de cas doit être une définition claire de toutes les options, en concluant avec un argument convaincant pour une implémentation de la solution proposée.
L’analyste métier doit confirmer qu’il comprend totalement :
Les organisations utilisent des indicateurs de performances clés (IPC) pour évaluer leur capacité à atteindre des cibles.
Les indicateurs de performances clés métier définissent des valeurs mesurables qui montrent l’efficacité avec laquelle une entreprise atteint les objectifs commerciaux clés. Il est important de sélectionner des IPC pertinents pour votre activité/scénario avec des définitions claires de leur nature, de la façon dont ils seront mesurés, de leur utilisation et des personnes qui les utiliseront.
Le document des exigences de l’entreprise décrit la solution d’entreprise pour un projet, en spécifiant clairement les besoins et attentes métier du client. Le document des exigences de l’entreprise distingue également la solution métier et la solution technique.
Lors de l’examen de la solution commerciale, l’outil BRD doit répondre à la question suivante :
"Que veut faire l'entreprise ?"
Les processus de l’évaluation des risques et des tests de pénétration peuvent produire des problèmes et des résultats qui doivent être gérés dans l’architecture ou le développement de la solution.
Tous les réglages provenant de ces processus doivent être vérifiés et approuvés par l’entreprise et évalués par rapport aux objectifs généraux.
La stratégie de mise en cache décrit ce qui sera mis en cache pour l’utilisateur final. Elle doit être compatible avec les IPC de performance.
Par exemple, des éléments tels que des images, du code JavaScript et d’autres fichiers de serveur peuvent être mis en cache de façon à améliorer la performance d’une solution.
Les consignes de codage définissent les principes de base que les développeurs doivent respecter lors du développement de la solution. Elles peuvent inclure, entre autres :
Assurez-vous que chaque personnage/rôle approprié a reçu le manuel des opérations.
Assurez-vous que chaque personnage/rôle approprié a reçu le rapport de test de performances.
Assurez-vous que chaque personnage/rôle approprié a reçu les notes de mise à jour.
Assurez-vous que l’équipe de projet a pleinement connaissance de la portée du projet, ainsi que des attentes pour la livraison et qu’elle est prête à s’y conformer.
Assurez-vous que chaque personnage/rôle approprié reçoit les documents de formation et les guides de l’utilisateur.
Assurez-vous que toutes les exigences de sécurité des clients sont en place.
Assurez-vous que le concept de sécurité est en place.
Aperçu des modèles et des composants qui seront utilisés dans la nouvelle application. Contient des informations telles que les règles d’héritage, les autorisations et les relations.
Détails du concept de relation entre les composants et les modèles.
Détails des spécifications de chacun des composants à mettre en œuvre.
Concept sur la façon de développer et de tester toutes les interfaces externes qui ne sont pas ouvertes/disponibles pour les environnements de développement ou de test.
Planifiez/mettez en œuvre les maquettes de ces interfaces pour assurer que les tests sont aussi proches que possible du comportement en production.
Documentation de l’architecture de contenu proposée. Les détails doivent inclure notamment :
Le contenu de système hérité est révisé et le contenu sélectionné est validé pour la migration vers la nouvelle solution.
Une version initiale du contrat juridique.
Documentation de l’architecture et du format du contenu actuel. Elle servira pour la génération de la future architecture de contenu. Elle est également utilisée pour le concept de migration.
Stratégies du client concernant :
Toutes les consignes/exigences du client sur la manière dont le développement doit être effectué.
Stratégies du client définissant quand et comment les déploiements/publications de versions peuvent être effectués.
Il s’agit souvent de chronologies, de la planification et des conditions d’approbation.
Stratégies et exigences du client sur ce qui doit être surveillé. Elles s’ajoutent à toutes les recommandations spécifiées dans le concept de surveillance.
La planification qui est définie par le client pour la publication des versions sur les environnements de production.
Toutes les stratégies et/ou exigences du client concernant les rapports. Elles peuvent inclure :
Établissez une feuille de route des principaux jalons à mettre en œuvre, aussi bien sur le plan technologique que métier. Cette feuille de route est ensuite communiquée au client.
Le client (métier et informatique) aura des stratégies qui définissent les niveaux de sécurité nécessaires pour la solution. Elles peuvent inclure :
Toutes les consignes du client relatives au format, à la diffusion et à l’approbation des spécifications.
Rapports du client pour le responsable de la qualité au cours de la période de test d’acceptation utilisateur.
Tous les correctifs et/ou personnalisations appliqués doivent être documentés, car ils peuvent affecter les futures mises à niveau :
AEM peut être hautement personnalisé selon vos besoins. Toutes les personnalisations qui peuvent affecter la mise à niveau doivent être entièrement documentées. Par exemple, toute modification majeure apportée à l’interface utilisateur d’AEM.
Toutes les mises à jour requises pour la solution actuelle doivent être entièrement documentées. Celles-ci peuvent inclure :
Rapports ou réunions résultant du test d’acceptation utilisateur. Ils doivent détailler :
Assurez-vous que les paramètres de sécurité par défaut d’AEM ont été activés/mis en œuvre.
Stratégies formalisées couvrant à la fois le déploiement et la ou les versions de votre projet. Elles peuvent inclure :
Définissez la fréquence requise des déploiements sur l’ensemble des environnements.
Une méthodologie de développement logiciel implique de diviser l’ensemble du processus de développement logiciel en phases (ou étapes) distinctes, chacune avec des activités qui lui sont propres. L’objectif est d’améliorer la planification et la gestion.
Lors de la définition de la méthodologie, vous devez prédéfinir les éléments livrables et les artefacts spécifiques qui sont créés par l’équipe de projet pour développer votre application ou en effectuer la maintenance.
Définissez quel développeur et/ou rôle réalise les tests informatiques (de performances ou autre) et/ou unitaires dans la solution.
Assurez-vous que l’environnement de développement est configuré avec les outils intégrés requis pour l’automatisation des déploiements.
L’équipe de développement doit confirmer qu’elle comprend totalement :
Détails des boîtes de dialogue requises pour la solution.
Documentation de l’environnement de développement.
Documentation de l’environnement de production.
Documentation de l’environnement de test.
Le test de durabilité indique les performances de la solution sous une charge spécifiée. Il mesure le temps de survie et les niveaux de performance de la solution en présence de la charge seuil.
Exécution du ou des tests de durabilité.
La gestion des erreurs se rapporte à l’anticipation, à la détection et la résolution des erreurs de programmation, d’application et de communication.
Documentation détaillée de la gestion des erreurs proposée, reposant sur le concept de gestion des erreurs.
Définition de tous les processus de réaffectation. Il existera des processus distincts pour chaque niveau du projet :
Organisez des réunions régulières d’examen de la qualité avec les membres appropriés de l’équipe.
Documentation du jeu existant d’autorisations et de groupes définis pour la solution héritée ou au sein de l’organisation.
Un schéma (ou un ensemble de schémas) des systèmes et des dépendances existants.
Le sponsor du projet collecte les attentes de l’entreprise associées à la réussite du projet. Il est important de disposer de l’ensemble des attentes disponibles au début d’un projet, car elles devraient influencer toutes les décisions prises tout au long de la mise en oeuvre.
Les exceptions peuvent inclure :
Exigences pour toute l’expérience de la solution. Elles couvrent des facteurs tels que la personnalisation, la persistance et l’expérience utilisateur interpériphérique.
Détails des exigences de conception de l’expérience.
Un schéma (ou ensemble de schémas) décrivant la totalité de l’écosystème de la solution. Il doit inclure des éléments tels que les intégrations, les interfaces, les dépendances et les réseaux externes.
La définition du système de secours comprend :
Test de bout en bout du système de secours.
Approbation des parties prenantes de l’entreprise signifiant que le système de secours et les procédures associées assureront les fonctionnalités métier stratégiques.
Résultats d’une étude de faisabilité à la fois pour AEM et la conception de haut niveau de la solution. Ils doivent être évalués par rapport aux IPC afin de s’assurer que ceux-ci peuvent être remplis.
Un contrat finalisé et signé est requis avant de poursuivre le projet. Il est basé sur la version préliminaire du contrat.
Confirmation que les parties prenantes acceptent entièrement :
Chronologie et planification des activités requises pour :
Les scénarios les plus simples sont des scénarios par défaut ne comprenant aucune condition exceptionnelle ou d’erreur. Ils sont composés de la séquence d’activités exécutée lorsque tout se passe comme prévu.
Estimations initiales des éléments suivants :
Confirmation que tous les environnements auront le matériel minimum requis en place.
La définition des exigences de haut niveau fournit une ventilation généralisée des exigences du système, couvrant notamment :
Les informations de base sur ces fonctions étant généralement connues, ce document ne doit pas être une estimation.
La conception de la solution de haut niveau explique l’architecture qui sera utilisée pour développer la solution. Le schéma d’architecture fournit une présentation de l’ensemble du système, identifiant les principaux composants qui seront développés pour le produit et leurs interfaces.
Cette carte système doit fournir un schéma de très haut niveau du système. Elle se différencie du contexte de la solution en ce qu’elle constitue une carte généralisée de tous les systèmes concernés ; aucune interface n’est représentée sur ce schéma.
Définition de la structure de contenu du système hérité. Elle est utilisée pour référence, mais également lors de la préparation de la stratégie de migration.
Vous devez recueillir et documenter les statistiques et les IPC de performance du système hérité. Ceux-ci sont ensuite utilisés comme point de référence et pour l’évaluation des performances de la nouvelle solution.
Liste des fonctionnalités métier stratégiques.
Mise en œuvre de toutes les modifications requises (qui ont été approuvées) de la solution d’après les résultats des tests de pénétration.
Configuration des outils et des processus nécessaires pour prendre en charge les tests automatisés.
Configuration du jeu d’outils et des processus nécessaires pour prendre en charge l’automatisation.
Mise en œuvre de l’architecture de contenu, des concepts de balisage et de la réutilisation du contenu.
Mise en œuvre des exigences pour prendre en charge la conception de l’expérience.
Mise en œuvre du système de secours et des procédures relatives.
Mise en œuvre des intégrations avec tous les systèmes externes requis.
Migration, ainsi que la validation du contenu et des autres artefacts, pour la nouvelle solution.
Mise en œuvre des rôles et des droits, des utilisateurs et des groupes.
Mise en œuvre de toutes les mesures de sécurité, y compris les paramètres par défaut d’AEM.
Mise en œuvre de la sécurité des applications logicielles.
Mise en œuvre de la sécurité du système.
Mise en œuvre du concept de gestion des URL.
Mise en œuvre des workflows conçus.
Le concept de mise en œuvre fournit les principes directeurs de l’ensemble de la mise en œuvre. Il doit prendre en compte les aspects suivants :
Ce concept peut également décrire les structures, les bibliothèques et d’autres artefacts utilisés dans la solution.
Contactez l’assistance d’Adobe pour vous assurer que toute prise en charge nécessaire puisse être activée pendant l’activation.
Concepts préliminaires pour les conceptions des expériences.
Test, et confirmation résultante, de toutes les intégrations, à la fois internes et externes.
Il devrait être automatisé et exécuté fréquemment pour garantir la stabilité du système.
Des processus clairs enregistrent tous les problèmes rencontrés et suivent les activités en cours dans le but de vérifier que tous les problèmes sont résolus.
Un système de suivi, ainsi que les processus requis, pour enregistrer tous les problèmes rencontrés et suivre les activités en cours dans le but de vérifier que tous les problèmes sont résolus.
Toutes les parties prenantes du projet doivent y avoir accès pour faciliter la transparence de l’état du projet.
Des exemples incluent Atlassian JIRA et HP Quality Center.
Les outils sélectionnés sont complètement intégrés et l’accès est accordé à tous les rôles requis.
Pour votre projet, le système hérité est la technologie, le système informatique ou le programme d’application existant qui sera remplacé par la nouvelle solution.
Les détails du système hérité doivent être collectés, de manière à savoir ce qui peut être retiré et à quel moment, ainsi que l’impact sur les autres systèmes.
Description des outils qui seront utilisés dans la mise en œuvre. Ils doivent inclure :
Liste de tous les utilisateurs et rôles qui ont besoin d’accéder au portail d’assistance d’Adobe.
La liste est généralement composée de l’architecte de la solution et/ou du personnel informatique du client.
Analyse, ainsi que les recommandations résultantes, définissant ce qui doit être consigné pour surveiller la solution :
Tester et activer les tâches de maintenance d’AEM telles que :
Documentez la migration, notamment :
Une description complète du contenu existant, de l’architecture du contenu et des formats associés à la nouvelle solution. Elle doit aborder :
Nous recommandons également de maintenir le contenu à jour (ou le plus à jour possible) au cours de la période entre la migration et l’activation du nouveau système. Il peut s’agir d’un blocage de contenu, d’une double publication ou de la maintenance d’un système alpha.
Surveillance de l’utilisation de l’unité centrale du système par la solution :
Surveillance des vitesses d’entrée et de sortie du disque de la solution :
Surveillance de l’utilisation de l’espace disque par la solution :
Vous devriez surveiller l’utilisation via :
Surveillez toutes les connexions entre la solution et les systèmes externes :
Surveillez l’utilisation de la bande passante réseau par la solution :
Surveillez les requêtes apportées à la solution.
Surveillez les points de sécurité définis.
Surveillez le système global, par exemple :
Surveillance du seuil défini de la solution, ainsi que de la mise en œuvre des étapes d’action pour réduire la charge.
Les concepts de surveillance à appliquer à votre solution, y compris :
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) :
Assurez-vous que les ingénieurs système et le personnel de production connaissent et comprennent toutes les stratégies de surveillance.
Définissez :
Toutes les tâches opérationnelles documentées et leur fréquence définie.
Manuel fournissant toutes les informations requises pour la réussite des opérations et la maintenance de la solution :
Il doit également décrire les concepts de mise en œuvre pour :
Module de l’application compilé et livré prêt pour le déploiement.
Un test de pénétration (également appelé « pen test » en anglais) est une attaque sur un système informatique qui recherche les failles de sécurité pouvant donner accès aux fonctions et aux données de l’ordinateur.
Tous les critères requis sont satisfaits.
Rapports créés pour l’entreprise expliquant les résultats des tests de pénétration.
Document conceptuel sur la manière de s’assurer que votre mise en œuvre satisfait les IPC de performance et de dimensionner la solution de sorte qu’elle continue à satisfaire ces IPC.
L’évaluation des performances permet de définir les tests de performances et de durabilité, ainsi que la surveillance. Pour ce faire, il évalue les caractéristiques de performance de la solution et du matériel système.
Ils définissent les indicateurs de performances clés (IPC) requis pour mesurer les performances du système. Il peut s’agir notamment du temps de chargement des pages, du temps de réponse du serveur, ainsi que de la performance des requêtes de la base de données.
Rapports créés pour l’entreprise, qui détaillent les résultats des tests de performance.
Les résultats doivent correspondre aux IPC et attentes définis en termes de performance.
Le test basé sur les personnages est une méthode basée sur les différents personnages décrite dans les conceptions de l’expérience. Il teste également les comptes et leurs niveaux d’autorisation associés.
Il est souvent utilisé dans les tests d’acceptation utilisateur.
La preuve de concept est évaluée par rapport aux exigences afin de s’assurer que les deux sont alignées.
Liste de contrôle pour définir la série de vérifications et de tâches à effectuer après chaque déploiement.
Liste de contrôle pour définir la série de vérifications et de tâches à effectuer avant chaque déploiement.
Il est habituel d’effectuer un test de ligne de base sur une installation AEM standard. Il est alors utilisé comme une évaluation des performances par rapport à laquelle tester la mise en œuvre et le matériel.
Vérifiez que l’environnement de production est prêt, avec les déploiements automatisés en place.
Avant l’activation sur l’environnement de production, l’approbation de production doit être accordée. Elle est le résultat d’une révision de la version qui ira en production, ainsi que de tous les problèmes connus. L’approbation est donnée dans le cadre de la planification de l’activation.
Stratégie et processus requis pour obtenir l’approbation de la production avant de passer le module dans l’environnement de production.
Définissez le plan de communication pour les parties prenantes de l’entreprise et l’équipe de projet.
Les estimations initiales étaient de haut niveau et établies selon les exigences de haut niveau pour la mise en œuvre.
Elles sont maintenant révisées, affinées et améliorées afin de fournir les estimations finales. Les estimations doivent être livrées par chaque responsable de projet approprié, y compris la gestion de projets, le consulting, l’architecture, le test et le développement.
Ces estimations sont utilisées pour la gestion des ressources et la budgétisation.
Les estimations initiales sont de haut niveau et établies selon les exigences de haut niveau pour la mise en œuvre. Elles seront révisées et affinées ultérieurement.
La documentation nécessaire pour décrire l’organisation et la structure hiérarchique du projet et de l’équipe.
Prend souvent la forme d’un graphique, ou inclut un graphique, pour fournir une présentation visuelle des chronologies et des responsabilités. Il existe de nombreux outils disponibles pour vous y aider.
Le document sur la portée du projet requiert que vous identifiez et documentiez une liste incluant les éléments suivants :
Il explique ce qui doit être atteint, ainsi que le travail à réaliser pour livrer le projet.
Les rapports sur l’état du projet livrés selon la planification convenue et dans le format requis.
La preuve de concept met en œuvre un choix limité de fonctions pour la solution.
Elle doit démontrer la faisabilité de la solution, vérifier qu’elle peut réaliser l’objectif requis et prouver qu’il existe un potentiel d’utilisation.
AEM conserve plusieurs versions des ressources et du contenu. Les règles de purge sont conçues et configurées pour supprimer régulièrement les anciennes versions afin de préserver l’intégrité et la taille du référentiel.
Définissez le contenu requis et le format du rapport de qualité, ainsi que la fréquence à laquelle il doit être livré.
Le chef de projet coordonne tous les rôles requis pour la publication en production.
Les notes de mise à jour font partie de la documentation de la version. Elles doivent englober :
Elles sont utilisées avec le runbook pour effectuer des étapes et des vérifications avant et après installation.
Pour obtenir un exemple, consultez les Notes de mise à jour AEM.
Version finale exécutée et active en production.
Vous devez mettre en évidence les conditions spécifiques du contrat qui sont pertinentes pour la mise en œuvre du projet, comme les jalons contractuels, les périodes de facturation ou les exigences en matière de personnel.
Avec le client, définissez la fréquence des rapports à leur remettre.
Les données ne sont jamais remplacées dans un fichier tar ; l’utilisation du disque augmente même si vous mettez uniquement à jour des données existantes.
Pour contrebalancer la taille en croissance perpétuelle du référentiel, une stratégie d’optimisation est mise en place de façon à supprimer les données obsolètes.
Demande officielle de configuration du projet sur le portail d’assistance d’Adobe.
Cet ensemble de documentation couvre les exigences fonctionnelles et non fonctionnelles, ainsi que les efforts prévus.
Assurez-vous que tous les rôles requis pour l’activation sont remplis et disponibles.
L’évaluation des risques est exécutée par le ou les départements informatique et/ou de sécurité du client.
Elle évalue les risques techniques et métier du projet. L’évaluation est requise pour assurer la conformité de la solution aux stratégies de sécurité.
Le plan d’atténuation des risques comprend l’évaluation des risques. Ensemble, ils abordent :
Définissez les attentes en termes de retour sur investissement associées à la solution.
Elles ont pour but d’indiquer l’efficacité de la solution en termes économiques en définissant les bénéfices/profits estimés par rapport aux investissements prévus.
Spécification détaillée des concepts associés aux rôles et aux droits d’accès requis pour la nouvelle application, y compris une description de haut niveau des :
Passez en revue le concept de rôles et de droits pour vous assurer qu’il respecte les stratégies de sécurité.
Spécification détaillée basée sur le concept de rôles et de concepts.
Recommandations relatives à la sécurité pour l’architecture logicielle et matérielle.
Ces consignes définissent la manière dont le codage de développement doit être effectué, en fonction des exigences de sécurité telles que :
Liste de contrôle spécifique au projet, basée sur le concept de sécurité ainsi que toute stratégie supplémentaire nécessaire pour assurer la conformité de la solution.
Elle est souvent également incluse dans le cadre des étapes de post-déploiement au sein du runbook.
Définissez et documentez les détails de la configuration de sécurité requis pour l’application, l’architecture et l’infrastructure.
Une description de haut niveau de la configuration de sécurité de :
Tous les problèmes de sécurité de la solution répertoriés et évalués ; y compris les estimations de l’effort.
Approbation des parties prenantes pour garantir que la mise en œuvre de la sécurité est conforme aux stratégies et aux attentes.
Mettez en place les processus de prise en charge requis.
Assurez-vous que les contrats de niveau de service sont disponibles et transmis aux équipes de développement et des opérations pour qu’elles puissent les utiliser lors de la mise en œuvre et de l’assistance.
Les tests de détection de fumée désignent un ensemble d’étapes définies qui testent les principales fonctionnalités de la solution pour assurer les opérations de base et la fonctionnalité de la solution.
Ils sont exécutés sur n’importe quel environnement après l’installation ou le déploiement.
Les tests de détection de fumée doivent être exécutés sur tous les systèmes pour assurer le bon fonctionnement de la fonctionnalité de base de la solution lors de l’installation ou du déploiement sur n’importe quel environnement.
Stratégie de haut niveau de l’architecture logicielle, incluant les services, les servlets, les structures et d’autres décisions de mise en œuvre.
Le conseil d’examen de la solution est généralement constitué des parties prenantes du côté client.
Le conseil organise des réunions régulières pour passer en revue de manière continue les exigences en cours d’étude et les spécifications pertinentes. L’objectif est de garantir la concordance avec la définition et les critères de réussite, et de fournir des suggestions dans le cadre du développement des exigences.
Instructions d’installation de la solution, ainsi que les tâches opérationnelles de base à effectuer sur l’installation.
Le processus d’approbation et d’acceptation décrit les critères qui doivent être remplis avant que la solution ne puisse être publiée dans un environnement de production.
Il peut également servir de jalon contractuel.
Concept initial pour toute fonctionnalité spéciale qui est considérée comme étant en dehors de la portée normale du développement sur la plate-forme AEM.
Détails de toute fonctionnalité spéciale qui est considérée comme étant en dehors de la portée normale du développement sur la plate-forme AEM.
Toutes les consignes sur la manière dont la spécification doit être effectuée.
Un processus clair doit être mis en place pour l’approbation des spécifications par le client. Ce processus garantit la clarté et la fermeté de la portée des exigences.
Personnel interne qui doit être formé pour administrer la solution.
Personnel interne qui doit être formé pour créer dans la solution.
Les parties prenantes sont les personnes et/ou les rôles clés qui ont un impact significatif sur le projet. Certaines contribueront au budget du projet.
Les parties prenantes peuvent être internes et/ou externes.
Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre ont connaissance :
Confirmation que toutes les parties prenantes en dehors de l’équipe de mise en œuvre sont alignées sur l’ensemble du projet et des attentes, à la fois en interne au sein de l’équipe de projet et chez le client.
Les rapports d’état sont un outil de communication clé. Le format doit être aligné sur toutes les exigences du client en ce qui concerne la création de rapports.
Le client, le sponsor du projet et le chef de projet ou le consultant doivent spécifier :
Ils sont utilisés pour vous assurer que les critères de réussite sont remplis :
L’une des responsabilités du responsable de la qualité est de s’assurer qu’il existe des ressources disponibles pour assister tout utilisateur lors des tests. Par exemple, afin d’aider l’utilisateur au cours des tests, lors du signalement des problèmes et afin d’aider à valider les problèmes par rapport à l’environnement de test.
L’accès au portail d’assistance d’Adobe est indispensable pour soumettre des tickets concernant tout problème concernant le produit qui peut se poser lors de la mise en œuvre.
L’accès doit être affecté aux membres clés de l’équipe.
Proposition et définition initiales de l’architecture pour tous les environnements de la solution.
Document détaillant l’architecture du système, y compris les interfaces, l’emplacement réseau et les intégrations pour tous les environnements, entre autres informations.
Description de haut niveau de la façon de rendre l’architecture du système conforme à toutes les stratégies de sécurité. Cela peut couvrir :
Tous les facteurs de risque identifiés dans l’évaluation des risques (ou d’autres révisions) sont identifiés et évalués :
Confirmation que l’ensemble de l’équipe est consciente des définitions et des critères de réussite.
Confirmation que tous les membres de l’équipe savent qui doit communiquer avec le client, comment et à quel moment.
Alignement avec l’ensemble du projet et des attentes, à la fois internes au sein de l’équipe de projet et chez le client.
Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.
Identifiez et vérifiez les risques techniques potentiels. Les risques techniques peuvent inclure :
Les spécifications techniques abordent (entre autres informations) :
Spécifications des modèles requis. Elles doivent englober les détails, y compris le système de paragraphe (parsys), le plan directeur et le mappage d’héritage, entre autres.
Les spécifications sont basées sur les exigences de l’entreprise et de l’expérience.
Les cas de test spécifient les étapes détaillées nécessaires pour exécuter le test fonctionnel de la solution.
Le contenu du test doit être le plus proche possible du contenu de production. Il doit s’agir d’une sélection suffisamment large pour permettre le test de tous les scénarios.
Assurez-vous que l’environnement de test est prêt, avec les déploiements automatisés en place afin de vous assurer que tout le code de la version finale (RC) est à jour à des fins de test.
Rapports détaillant les résultats des tests, notamment :
Il convient de noter les éléments suivants :
Sélection des outils et de la suite d’automatisation. Ils seront utilisés pour automatiser les tests, y compris ceux des cas d’utilisation.
Outils et suite d’automatisation sélectionnés pour l’automatisation de cas d’utilisation et d’autres tâches d’exécution des tests.
Le concept de test est la description de très haut niveau des tests du projet, notamment, l’assurance qualité, ainsi que les tests d’acceptation par les utilisateurs, de performance, de sécurité et d’intégration.
Ces plans décrivent en détail l’exécution des tests pour chaque phase du développement et sont basés sur la stratégie de test.
Ces exigences sont spécifiques à la mise en œuvre technique des services qui prennent en charge la solution.
La stratégie de test décrit la stratégie de haut niveau pour l’assurance qualité et les tests d’acceptation utilisateur. Cela inclut les chronologies, la fréquence des rapports et l’exécution.
Concept architectural et de niveau système pour l’intégration aux systèmes tiers.
Détails des exigences (fonctionnelles et non fonctionnelles) pour la prise en charge de la fonctionnalité et de l’intégration des systèmes tiers.
Concept pour garantir la sécurité de toutes les intégrations tierces. Doit être compatible avec les stratégies de sécurité appropriées.
Assurez-vous que tous les systèmes tiers sont disponibles, ainsi que la documentation appropriée, pour la mise en œuvre de l’intégration.
Droits d’accès requis octroyés aux rôles correspondants utilisés conjointement avec les systèmes tiers.
Définit :
Définit les valeurs clés des points de surveillance au sein du système.
Par exemple :
Cela doit définir les chronologies et les jalons contractuels du projet à utiliser pour :
Toutes les estimations des efforts de chacun des responsables du projet doivent être consolidées, notamment les efforts de surcharge, de développement, d’ingénierie système, d’architecture et de test.
S’il existe un niveau d’assistance inclus dans l’accord, les efforts de prise en charge et de production doivent également être inclus.
Supports à utiliser dans les sessions de formation. Les supports doivent être créés spécifiquement pour la solution et conçus pour être utilisés conjointement avec les guides de l’utilisateur.
Le personnage approprié doit confirmer qu’il comprend totalement :
Le concept de gestion des URL doit inclure les fonctionnalités d’URL spécifiques à AEM, notamment :
Le concept doit également inclure :
Un cas d’utilisation constitue la liste des actions ou des étapes d’événements nécessaires pour atteindre un objectif. En règle générale, ils définissent les interactions entre un rôle et la solution. Le rôle peut être un utilisateur ou un système externe.
Les scénarios de test sont basés sur les cas d’utilisation techniques et métier. Ils sont utilisés pour tester que le comportement de la solution fonctionne comme prévu.
Les guides de l’utilisateur fournissent des informations et de l’assistance pour les utilisateurs de la solution :
Le plan budgétaire doit être révisé et validé par toutes les parties prenantes. Elles doivent vérifier les informations comme la facturation, les montants et les méthodes/échéances des rapports sur le budget.
Les tests boîte blanche suivent une méthode qui examine les structures ou mécanismes internes d’une application, par opposition à sa fonctionnalité. Les tests boîte blanche peuvent être appliqués au niveau des unités, de l’intégration et des systèmes du processus de test logiciel.
Basées sur le concept des workflows, ces spécifications doivent définir, en détail, les étapes qui créent le workflow complet.
La spécification de chaque workflow doit inclure (au minimum) :
Les workflows permettent d’automatiser les activités d’AEM. Le concept des workflows décrit :