La Liste de contrôle – Référence supplémentaire the-checklist-further-reference
Cette page fournit des détails supplémentaires sur les documents et principes couverts par la Gestion des projets - Liste de contrôle des bonnes pratiques.
AEM - Que voulez-vous utiliser ? aem-what-will-you-be-using
Fonctionnalités d’AEM features-within-aem
Lors de la mise en œuvre d’AEM (notamment pour la première fois), vous devez passer en revue les fonctionnalités et les workflows d’AEM afin de connaître avec certitude les domaines souhaités/requis.
Tenez compte des fonctions d’AEM que vous utiliserez et de l’impact sur votre travail de conception, par exemple :
Vérifiez également la variable Notes de mise à jour, pour les différentes versions d’AEM, pour savoir quand de nouvelles fonctionnalités ont été ajoutées.
Intégrations integrations
AEM peut être intégré à d’autres produits Adobe et/ou services tiers. Ceux-ci peuvent augmenter la puissance et les fonctionnalités à votre disposition.
Voir Intégration de solutions pour obtenir des informations complètes.
Migrer ou mettre à niveau ? migrate-or-upgrade
Il est important de déterminer si vous souhaitez :
- Mettez à niveau l’installation existante.
- Migrez le contenu du système actuel vers une nouvelle installation.
Lorsque vous passez d’une version précédente à la version actuelle, deux options sont disponibles :
- Utilisez la variable Gestionnaire de modules pour exporter tout le contenu et le code de l’application de l’ancien système vers le nouveau.
- Mettre à niveau l'ancien système en place. Il s’agit du choix recommandé dans la plupart des cas.
Règles de base basic-ground-rules
Comme pour tout projet, il est essentiel d'établir des règles de base dès que possible. Celles-ci comprennent les éléments suivants :
-
Rôles
Ils doivent être clairement définis et connus de tous ceux qui participent au projet. En outre, il est conseillé de mettre en évidence :
- Décideurs
- Points de contact
-
Responsabilités
- Pour chaque rôle, une définition claire des responsabilités liées à votre projet permet d’éviter toute confusion.
-
Implication
En impliquant dès que possible les parties intéressées, vous pouvez les encourager à devenir parties prenantes dans le projet, augmentant ainsi leur engagement pour son succès.
- Du côté client, cela inclut les auteurs qui devront travailler avec le système au quotidien.
- Au sein de votre propre équipe de projet, cela inclut également les personnes responsables de l’assurance qualité. Plus ils comprennent les exigences du client, mieux ils peuvent planifier les tests.
-
Chemins de la communication
- Bien que celles-ci ne doivent pas être trop formalisées, des définitions spécifiques doivent veiller à ce que les personnes principales soient toujours informées. Une attention particulière doit être portée à la communication avec les parties externes.
-
Processus
Les processus à définir dépendent de votre projet individuel. Essayez encore de les simplifier en tenant compte des éléments suivants :
- définir des processus (et chemins de communication) pour interagir avec des tiers, le cas échéant ; par exemple, les agences de conception et les fournisseurs de logiciels tiers.
- Souvent, le client dispose de ses propres procédures et outils de gestion de projet et de reporting.
-
Outils de suivi
De nombreux outils sont disponibles pour effectuer le suivi d’informations sur les bogues, les tâches et d’autres aspects de votre projet. Voir Présentation des outils potentiels pour plus d’informations.
- Le point essentiel à noter ici est de ne conserver qu'une seule copie de l'information et de la partager (et donc de l'accès à l'outil utilisé). Cela facilite la maintenance et permet d’éviter les incohérences.
-
Portée
Définissez clairement ce qui doit être couvert par le projet à différents niveaux :
- les versions individuelles (si un processus de publication itératif est utilisé, et qu’elles soient diffusées aux clients ou à votre équipe de test interne).
- le projet AEM.
- l'ensemble du projet; y compris les logiciels tiers, leur impact sur les tests, les problèmes d’organisation et bien d’autres.
- Pour certains aspects, il peut également être utile d’indiquer ce qui est not dans le cadre du projet. Cela peut aider à éviter la confusion et des hypothèses incorrectes, bien qu'il doive se limiter aux problèmes essentiels.
-
Création de rapports
Définissez clairement quelles informations vous allez signaler, sous quelle forme, à quelle fréquence et à qui.
-
Terminologie
- Définissez les abréviations et/ou la terminologie spécifique au client à utiliser.
-
Hypothèses
- Définissez les hypothèses faites.
Ces informations peuvent être définies dans un manuel de projet ; l’utilisation d’un wiki peut également vous assurer que les modifications en cours sont gérées efficacement. Lorsqu’elles sont définies, les principaux facteurs sont les suivants :
- Les informations sont définies et conservées.
- L'information est clairement communiquée à toutes les personnes concernées. Bien que la gestion de projet soit une pratique standard, elle ne peut pas être répétée assez souvent pour qu’une définition claire des rôles et une bonne communication puissent créer ou interrompre un projet.
- Une seule version des informations suivies est conservée ; par exemple, le suivi des bogues, le suivi des problèmes, etc.
Indicateurs de performance clés et mesures cibles key-performance-indicators-and-target-metrics
Les organisations utilisent des indicateurs de performances clés (IPC) pour évaluer leur capacité à atteindre des cibles. Ces indicateurs sont des valeurs mesurables qui peuvent être utilisées pour démontrer l’efficacité avec laquelle des objectifs spécifiques sont atteints.
Ces indicateurs peuvent être les suivants :
-
Entreprise:
- Utilisé pour mesurer les objectifs commerciaux clés.
- Il est important de choisir les indicateurs de performance clés appropriés à votre entreprise/scénario avec des définitions claires de ce qu’ils sont, de la manière dont ils seront mesurés, de la manière dont ils seront utilisés et par qui.
-
Performances :
- Définissez comment 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.
Certains indicateurs, mais pas tous, peuvent être basés sur les mesures cibles que vous identifiez et définissez.
Mesures Target target-metrics
Les mesures servent à définir des mesures quantitatives de la qualité de votre site web. Elles sont essentiellement une définition des objectifs de performances que vous souhaitez atteindre et peuvent être utilisées pour définir votre IPC (indicateurs de performance clés).
De nombreuses mesures peuvent être définies, mais souvent celles que vous définissez couvrent vos objectifs en termes de performances et de simultanéité. En particulier, des facteurs qui peuvent être difficiles à quantifier et qui sont souvent sujets à des émotionnel évaluation :
-
"notre site web est beaucoup trop lent aujourd’hui" - quand lent être admissible ?
-
"tout grinçant à un arrêt lorsque mon collègue se connecte". Combien d’utilisateurs simultanés le système peut-il prendre en charge ?
-
"lorsque je recherche, le système grinçant à un arrêt " - quel type de requêtes de recherche impacte le système ?
-
"Il faut âges télécharger le fichier". Quelles sont les heures de téléchargement acceptables (dans des conditions réseau normales) ?
Les mesures Target sont définies au début d’un projet pour :
- indiquer les dimensions attendues du site web que vous proposerez ;
- indiquer la qualité minimale à atteindre ;
- définir comment ces facteurs seront réellement mesurés ;
- doit être utilisé comme base pour la variable Indicateurs de performance clés
Comme toujours, vous devez être prudent lors de la définition des mesures cibles :
- s’ils sont trop élevés, ils peuvent être complètement inaccessibles.
- si elle est définie sur de trop faibles fluctuations peut ne pas être mise en évidence.
- pour s’assurer qu’elles peuvent être mesurées de manière répétée et cohérente.
- afin de fournir un équilibre entre les différents facteurs mesurés.
- certaines mesures se rapportent à un environnement de test, mais certaines doivent refléter des scénarios de la vie réelle, car elles doivent être mesurables et reproductibles, sur votre site web de production.
- classer par priorité les mesures en fonction de leur importance pour le site web
- limiter les mesures à un ensemble pouvant être surveillé de manière réaliste ;
Au cours du développement du projet, elles peuvent être mises à jour et ajustées selon les besoins. Une fois le projet mis en oeuvre avec succès, vous pouvez les utiliser pour contrôler votre installation et surveiller/gérer les niveaux de service requis pour le fonctionnement en cours.
Si elles sont correctement utilisées, ces mesures peuvent fournir un outil utile. En revanche, si elles sont utilisées de manière irresponsable, elles peuvent constituer une distraction et une perte de temps. Comme toujours, vous devez comprendre ce que vous mesurez, comment vous le mesurez et pourquoi.
Tout repose sur la conception de projet everything-rests-on-your-project-design
Toutes les mesures à mesurer seront, d’une certaine manière, affectées par la conception de votre projet. Inversement, de nombreux problèmes seront mieux résolus par des modifications de conception.
Par conséquent, vous devez définir vos mesures cibles. before décider de votre conception. Cela vous permet d’optimiser votre conception en fonction de ces facteurs. Une fois votre projet développé, il sera difficile d’apporter des modifications aux principes de conception de base.
Lorsque vous créez la structure du site web, suivez la structure recommandée pour AEM sites web. Assurez-vous de comprendre les problèmes et/ou principes suivants :
- Comment structurer le contenu d’un site web.
- Fonctionnement des modèles et des composants.
- Fonctionnement de la mise en cache.
- Les impacts du contenu personnalisé.
- Fonctionnement de la fonction de recherche.
- Comment utiliser le code CSS et les technologies associées pour créer du code de HTML compact et non redondant.
Si vous estimez que votre conception ne suit pas les instructions ou si vous n’êtes pas certain de certaines implications, clarifiez ces questions avant de commencer la phase de programmation ou de compléter le contenu.
Infrastructure infrastructure
Pour définir ou évaluer l’infrastructure, il aidera à définir des valeurs cibles telles que :
- visiteurs/jour ; moyenne et pic
- accès/jour ; moyenne et pic
- nombre de pages web mises à disposition
- volume de contenu web
En fonction de votre situation et de l’importance stratégique du site web, cela vous aidera à évaluer et à choisir votre infrastructure :
- nombre de serveurs
- nombre d’instances d’AEM (auteur et publication)
Performances performance
Plusieurs facteurs de performances peuvent être évalués :
-
temps de réponse pour des pages individuelles, en tenant compte des éléments suivants :
- temps de réponse dans un environnement de création
- temps de réponse dans l’environnement de publication
-
temps de réponse des requêtes de recherche
Cette section peut être lue en parallèle de la section Optimisation des performances qui répertorie les détails techniques relatifs à la mesure des performances.
Temps de réponse pour des pages individuelles response-times-for-individual-pages
L’un des problèmes majeurs est le temps que met votre site web pour répondre aux requêtes des visiteurs et des visiteuses.
Bien que cette valeur varie pour chaque requête, une valeur cible moyenne peut être définie. Une fois que cette valeur s’est avérée à la fois réalisable et gérable, elle peut être utilisée pour surveiller les performances du site web et indiquer le développement de problèmes potentiels.
Cibles différentes sur les environnements de création et de publication
Les temps de réponse que vous viserez seront différents dans les environnements de création et de publication, reflétant l’audience cible :
-
Environnement de création
Cet environnement est utilisé par les auteurs qui saisissent et mettent à jour du contenu. Il doit donc :
- prendre en charge un petit nombre d’utilisateurs qui génèrent un grand nombre de requêtes lors de la mise à jour des pages de contenu et des éléments individuels sur ces pages ;
- être aussi rapide que possible afin d’optimiser leur productivité pour intégrer du contenu à votre site web ;
-
Environnement de publication
Cet environnement intègre le contenu que vous mettez à la disposition de vos utilisateurs et utilisatrices :
-
La vitesse reste vitale, mais elle est souvent plus lente qu’un environnement de création
-
d’autres mécanismes d’amélioration des performances sont souvent appliqués :
- le contenu est mis en cache.
- l’équilibrage de charge est appliqué ;
-
Définition des délais de réponse des cibles setting-target-response-times
Comment puis-je décider des temps de réponse (moyens) atteignables ? Il s’agit souvent d’une question d’expérience :
- expérience passée sur votre site web
- expérience avec AEM
- identification des pages complexes dont les temps de réponse sont supérieurs à la moyenne (ces temps doivent être optimisés individuellement, si possible) ;
Toutefois, dans des circonstances contrôlées, les directives suivantes peuvent être appliquées :
- 70 % des demandes de pages doivent répondre en moins de 100 ms.
- 25 % des demandes de pages doivent répondre en moins de 100 à 300 ms.
- 4 % des demandes de pages doivent répondre en moins de 300 à 500 ms.
- 1 % des demandes de pages doivent répondre en moins de 500 à 1 000 ms.
- Aucune page ne doit répondre plus d’une seconde.
Les chiffres ci-dessus supposent les conditions suivantes :
- mesurées lors de la publication (aucun environnement de création et/ou surcharge CFC) ;
- mesuré sur le serveur (aucune surcharge réseau) ;
- non mis en cache (pas de cache AEM sortie, pas de cache de Dispatcher)
- uniquement pour les éléments complexes avec de nombreuses dépendances (HTML, JS, PDF, etc.) ;
- aucune autre charge sur le système
Vous pouvez utiliser plusieurs mécanismes pour surveiller les temps de réponse :
-
Surveillance des temps de réponse avec request.log AEM
Le journal des requêtes est un point de départ intéressant pour l’analyse de performances. Entre autres informations, vous pouvez l’utiliser pour afficher les temps de réponse des requêtes individuelles. Voir Optimisation des performances pour plus d’informations.
-
Surveillance des temps de réponse avec des commentaires HTMLS
*HTML comments* can be used to include response time information within the source of each page:</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
Requêtes de recherche search-requests
Les requêtes de recherche peuvent avoir un impact significatif sur votre site web, en termes de :
-
Temps de réponse de la recherche réelle
- Une fonction de recherche rapide est un objectif de qualité pour votre site web.
-
Impact sur les performances générales
- Comme une fonction de recherche doit analyser (potentiellement de grandes) sections du contenu, ou un index spécialement extrait, cela peut avoir une incidence sur les performances de l’ensemble du système si ce n’est pas optimisé.
La définition de cibles pour les requêtes de recherche est, encore une fois, une question d’expérience en fonction des éléments suivants :
- expérience de l’AEM
- une évaluation de la fréquence d’utilisation de la recherche par rapport à d’autres objectifs ;
- votre gestionnaire de persistance
- votre index de recherche
- la complexité de votre fonction de recherche ; une fonction de recherche de base qui ne permet d’entrer qu’un seul terme de recherche sera plus rapide qu’une recherche avancée permettant à l’utilisateur de créer des instructions de recherche complexes à l’aide de AND/OR/NOT.
Elles doivent être planifiées et intégrées dès le début de votre projet. Les mécanismes de surveillance disponibles sont les suivants :
-
Surveillance des temps de réponse de la recherche avec l’AEM request.log
Là encore, le fichier request.log peut être utilisé pour surveiller les temps de réponse des requêtes de recherche ; see Optimisation des performances pour plus d’informations.
-
Mécanismes programmés pour mesurer les temps de réponse des recherches
Pour personnaliser les informations que vous collectez sur les requêtes de recherche et leurs performances, il est recommandé d’inclure la collecte d’informations dans le code source de votre projet ; see Optimisation des performances pour plus d’informations.
Concurrence concurrency
Votre site web sera mis à la disposition de plusieurs utilisateurs/visiteurs, dans les environnements de création et de publication. Les nombres sont souvent plus élevés que ceux que vous utilisiez lors des tests, mais aussi fluctuants et difficiles à prédire. Votre site web devra être conçu pour un nombre moyen d’utilisateurs/de visiteurs simultanés sans remarquer un impact négatif sur les performances. Là encore, le fichier request.log peut être utilisé pour effectuer des tests d’accès simultané ; consultez Optimisation des performances pour plus d’informations.
Les cibles pour le nombre d’utilisateurs simultanés dépendent du type d’environnement :
-
Environnement de création
- Généralement, le nombre d’utilisateurs simultanés peut être estimé avec précision. Vous saurez combien d’auteurs vous avez au total, bien que (probablement) tous ne seront pas principaux en même temps.
-
Environnement de publication
- Cela est plus difficile à prédire. Vous devez donc sélectionner une valeur cible. Là encore, cela doit être basé sur l’expérience de votre site web actuel et sur des attentes réalistes de votre nouveau site web.
- Les événements spéciaux (par exemple, lorsque vous publiez du nouveau contenu très populaire) peuvent dépasser les attentes, voire même les capacités (comme cela est parfois rapporté dans la presse lorsque des billets pour certains événements sont mis en vente).
Capacité et volume capacity-and-volume
Avant de discuter des mesures connexes, une définition rapide des termes :
-
Volume
- La quantité en sortie qui est traitée et diffusée par le système.
-
Capacité
- Capacité du système à fournir le volume.
- À chaque étape, la capacité et le volume sont mesurés différemment, comme le montre le tableau ci-dessous. Pour de meilleures performances, assurez-vous que la capacité correspond au volume à chaque étape et que la capacité et le volume sont partagés à l’échelle de toutes les étapes. Par exemple, vous pouvez calculer la navigation sur l’ordinateur client ou la mettre dans le cache, au lieu de la calculer sur le serveur pour chaque requête.
-
Capacité et volume
table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3 Quoi / Où Capacité Volume Client Puissance de calcul de l’ordinateur de l’utilisateur. Complexité de la mise en page. Réseau Bande passante réseau. Taille de la page (code, images, etc.). Cache du Dispatcher Mémoire serveur du serveur Web (mémoire principale et disque dur). Serveur web (mémoire principale et disque dur). Nombre et taille des pages mises en cache. Cache de sortie Mémoire serveur du serveur AEM (mémoire principale et disque dur). Nombre et taille des pages dans le cache de sortie, et nombre de dépendances par page. Le cache du Dispatcher réduit ce volume. Serveur web Puissance de calcul du serveur Web. Nombre de requêtes. La mise en cache réduit ce volume. Modèle Puissance de calcul du serveur web. Complexité des modèles. Référentiel Performances du référentiel. Nombre de pages chargées à partir du référentiel.
Autres mesures other-metrics
Les sections précédentes détaillent les principales mesures à définir.
En fonction de vos besoins spécifiques, il peut s’avérer utile de définir des mesures supplémentaires, soit isolément, soit en tenant compte des classifications ci-dessus.
Cependant, il est préférable de disposer d’un petit ensemble de mesures principales précises et fiables, plutôt que d’essayer de mesurer et de définir chaque aspect de votre site web. Par sa nature même, votre site web commencera à changer et à évoluer dès qu'il sera transmis à vos utilisateurs.
Sécurité security
La sécurité est cruciale et présente un défi toujours plus grand. It must être considéré et planifié dès les premières étapes de votre projet.
La liste de contrôle de sécurité décrit les mesures à prendre pour s’assurer que votre installation d’AEM est sécurisée lors de son déploiement. D’autres aspects liés à la sécurité sont traités dans les sections Sécurité (lors du développement) et Administration des utilisateurs et sécurité.
Tâches parallèles et itératives parallel-and-iterative-tasks
- Cette section offre un aperçu de la première mise en œuvre d’un projet AEM.
- est conçu comme un aperçu abstrait ; voir la Liste de contrôle du projet pour des phases/jalons/tâches spécifiques.
- Toutes les échelles de temps sont théoriques.
Pour une nouvelle mise en oeuvre d’un projet AEM standard, vous devez tenir compte de tâches telles que :
- Transfert à partir du processus de vente.
- Mise en oeuvre de l’application client (Développement).
- Installation et configuration de l’infrastructure (et des processus associés) sur le site du client (Infrastructure).
- Création (ou migration) du contenu (Contenu).
- Transfert vers les opérations (Maintenance/assistance).
- Suivez les versions.
Pour tous les aspects, il est recommandé d’utiliser une approche itérative :
Voici quelques points à noter pour chaque catégorie :
-
Développement
-
Définissez d’abord l’architecture de base.
-
Utilisez plusieurs itérations (sprints) pour le développement :
- Le premier sprint correspond au premier cycle de développement complet.
- Le premier sprint entraîne le premier déploiement dans votre environnement de test.
- Chaque sprint a un résultat exécutable.
- Chaque sprint reçoit une approbation client (minimum de test structuré avec commentaires).
-
Planifiez l’éventualité d’une mise à jour de la version d’AEM disponible au cours du projet.
-
Planifiez les tests et l’optimisation lors des tirages.
-
Planifiez les phases de stabilisation et d’optimisation.
-
Créez un journal des éléments à planifier pour les prochaines versions.
-
Planifiez la participation et la remise des partenaires.
-
-
Infrastructure
-
Définissez d’abord l’architecture de base :
- Définissez les exigences de performances.
- Définissez des objectifs de performances (c’est-à-dire définissez clairement les attentes).
- Définir l’architecture du matériel et de l’infrastructure ; y compris le dimensionnement.
- Définissez le déploiement.
-
utiliser plusieurs itérations ; pour la préparation du premier sprint et de la configuration initiale :
- Environnement de développement.
- Processus de développement.
- Environnement de test.
- Processus de déploiement (y compris la gestion de la configuration).
-
Planifiez plusieurs tests de charge.
-
Planifiez les tests et l’optimisation lors des tirages.
-
Planifiez une phase de stabilisation et d’optimisation.
-
Déployez dans l’environnement de production dès que possible (laissez l’équipe d’exploitation configurer le système pour acquérir de l’expérience).
-
Utilisez aussi tôt que possible les utilisateurs nommés et les rôles définis.
-
Planifiez la formation (formation des administrateurs, par exemple).
-
Planifiez la remise aux opérations.
-
-
Contenu
-
L’architecture de base :
- Permet d’orienter la hiérarchie du contenu.
- Permet de définir le concept de contenu.
- Définit l’utilisation et la mise en page MSM.
- Définit les rôles, les groupes, les workflows et les autorisations.
-
Déterminez si la création de pages hors ligne sera utile.
-
Planifiez la création précoce des premières pages et du contenu (à utiliser dans les tests et les commentaires).
-
Planifiez la migration du contenu existant.
-
Planifiez la "migration interne au sprint" après la refactorisation.
-
Planifiez le "chargement du contenu" (plan du site pour le contenu de mise en ligne).
-
Estimation du temps et des efforts estimating-time-and-effort
En fonction de la liste des tâches qui en résulte, vous pouvez ensuite effectuer des estimations initiales du temps et de l’effort pour les définitions de tâches (de haut niveau). Elles doivent inclure une indication de qui (client ou partenaire) fera quoi et quand.
La liste suivante présente les approximations standard et les corrélations d'effort connexes, et donc les coûts :
Une planification détaillée peut ensuite relier les ressources disponibles ou requises aux échéances et aux coûts.
Architecture de référence reference-architecture
L’architecture de référence est fournie pour fournir une solution de modèle pour l’architecture AEM. L’architecture de référence résout les problèmes courants rencontrés pour les systèmes d’entreprise, notamment la mise à l’échelle, la fiabilité et la sécurité.
Les mesures de site suivantes doivent être définies :
Présentation des outils potentiels overview-of-potential-tools
La liste suivante est fournie pour vous informer des outils qui peuvent être utilisés. Il s’agit d’une introduction, et non d’une liste de recommandations exhaustive, qui ne devrait certainement pas vous dissuader d’utiliser d’autres outils que vous préférez.
Informations complémentaires further-reading
En outre, les sections suivantes présentent un intérêt particulier :
Bonnes pratiques best-practices
Adobe fournit d’autres bonnes pratiques pour toutes les phases et audiences :