Y a-t-il des parties du code qui n'ont pas été modifiées depuis longtemps ?
Le code legacy est-il bien documenté ?
Existe-t-il des dépendances à des technologies ou des frameworks obsolètes ?
Combien de bugs sont associés aux parties legacy du code ?
Le code legacy suit-il les standards de codage actuels de l'organisation ?
Quel est le temps nécessaire pour comprendre et modifier le code legacy ?
Y a-t-il des modules ou des classes qui sont surchargés de responsabilités ?
Les tests unitaires couvrent-ils le code legacy ?
Quels sont les retours des développeurs sur le code legacy ?
Existe-t-il des redondances ou du code dupliqué dans le code legacy ?
Les standards de codage sont-ils définis et documentés ?
Les développeurs respectent-ils les standards de codage ?
Quelle est la qualité de la documentation dans le code ?
Y a-t-il des outils de vérification automatique de la qualité du code en place ?
Le code est-il cohérent en termes de style et de structure ?
Les revues de code sont-elles régulièrement effectuées ?
Combien de warnings et d'erreurs sont générés par les outils d'analyse statique du code ?
Le code est-il modulable et réutilisable ?
Quelle est la complexité cyclomatique du code ?
Y a-t-il des pratiques de développement modernes en place (par exemple, programmation orientée objet, programmation fonctionnelle, etc.) ?
Quelle est la couverture de code actuelle par les tests ?
Existe-t-il des tests unitaires pour toutes les fonctionnalités critiques ?
Les tests sont-ils automatisés ?
Les tests sont-ils régulièrement exécutés ?
Quelle est la qualité des tests écrits ?
Les tests couvrent-ils les cas d'erreur et les cas limites ?
Quel est le temps d'exécution des tests ?
Les tests sont-ils maintenus et mis à jour avec les changements de code ?
Y a-t-il une politique de revue de tests en place ?
Les tests sont-ils isolés et indépendants les uns des autres ?
L'architecture du système est-elle documentée ?
L'architecture respecte-t-elle les principes de conception modernes ?
L'architecture est-elle modulaire et extensible ?
Le design permet-il une scalabilité horizontale et verticale ?
Y a-t-il des points de défaillance uniques (SPOF) dans l'architecture ?
Les composants de l'architecture sont-ils découplés et indépendants ?
L'architecture prend-elle en compte la sécurité dès la conception ?
L'architecture est-elle alignée avec les besoins métiers et les objectifs de l'organisation ?
Le système est-il conçu pour une résilience et une tolérance aux pannes ?
Comment les décisions d'architecture sont-elles prises et documentées ?
La documentation technique est-elle complète et à jour ?
La documentation est-elle accessible à tous les membres de l'équipe ?
La documentation est-elle bien structurée et facile à naviguer ?
Les guides d'installation et de configuration sont-ils clairs et complets ?
Les descriptions des API et des interfaces sont-elles détaillées et précises ?
Y a-t-il une documentation des processus de développement et de déploiement ?
Les diagrammes et illustrations sont-ils utilisés de manière efficace ?
La documentation inclut-elle des informations sur les meilleures pratiques et les normes de codage ?
Les procédures de dépannage et les FAQ sont-elles disponibles et utiles ?
Y a-t-il un processus en place pour maintenir et améliorer la documentation ?
Quelles sont les principales dépendances externes utilisées dans le projet ?
Les dépendances externes sont-elles à jour ?
Les dépendances externes sont-elles maintenues et activement développées ?
Y a-t-il des vulnérabilités de sécurité connues dans les dépendances externes ?
Les licences des dépendances externes sont-elles compatibles avec les politiques de l'organisation ?
Quelle est l'impact de l'obsolescence potentielle des dépendances ?
Les dépendances externes sont-elles bien intégrées et gérées dans le projet ?
Y a-t-il des tests spécifiques pour les fonctionnalités fournies par les dépendances externes ?
Quel est le plan de secours en cas de défaillance ou d'indisponibilité des services tiers ?
Comment les dépendances externes sont-elles documentées ?
Les politiques de sécurité sont-elles documentées et accessibles à tous les membres de l'équipe ?
Y a-t-il des procédures en place pour la gestion des vulnérabilités ?
Les données sensibles sont-elles chiffrées en transit et au repos ?
Des audits de sécurité réguliers sont-ils effectués ?
Les accès aux systèmes et aux données sont-ils contrôlés et limités en fonction des rôles ?
Un plan de réponse aux incidents est-il en place ?
Les employés reçoivent-ils une formation régulière sur la sécurité ?
Les systèmes et les applications sont-ils régulièrement mis à jour et corrigés ?
La conformité aux réglementations et aux normes de l'industrie est-elle régulièrement vérifiée ?
Y a-t-il des mécanismes de surveillance et de détection des intrusions en place ?
Quels sont les indicateurs de performance clés (KPIs) utilisés pour mesurer les performances du système ?
Y a-t-il des tests de performance réguliers effectués sur le système ?
Le système est-il capable de gérer des pics de charge sans dégradation des performances ?
Quelle est l'architecture actuelle en termes de scalabilité horizontale et verticale ?
Les goulots d'étranglement potentiels ont-ils été identifiés et traités ?
Les ressources sont-elles correctement dimensionnées pour les besoins actuels et futurs ?
Y a-t-il des mécanismes en place pour surveiller en temps réel les performances du système ?
Les stratégies de mise en cache sont-elles efficaces ?
Le système utilise-t-il des techniques de répartition de charge (load balancing) ?
Comment les incidents de performance sont-ils traités et résolus ?
Existe-t-il une documentation complète des configurations système et des paramètres ?
Utilisez-vous des outils de gestion de configuration (CM) ?
Les configurations sont-elles versionnées et traçables ?
Existe-t-il des processus de revue et d'approbation des changements de configuration ?
Les déploiements sont-ils automatisés ?
Les environnements de développement, de test et de production sont-ils cohérents ?
Comment gérez-vous les secrets et les informations sensibles dans les configurations ?
Les déploiements incluent-ils des étapes de validation et de test ?
Comment les incidents liés aux configurations sont-ils détectés et résolus ?
Y a-t-il un plan de retour en arrière (rollback) en cas de déploiement échoué ?
Existe-t-il une documentation claire et à jour pour les procédures de maintenance ?
Y a-t-il une équipe dédiée à la maintenance et au support ?
Quels outils de suivi des incidents et des demandes de support sont utilisés ?
Quel est le temps moyen de résolution des incidents ?
Les incidents sont-ils correctement priorisés en fonction de leur impact et de leur urgence ?
Les correctifs et mises à jour sont-ils régulièrement appliqués ?
Y a-t-il des tests post-maintenance pour garantir la stabilité du système ?
Les utilisateurs finaux sont-ils satisfaits du support reçu ?
Des audits de maintenance réguliers sont-ils effectués ?
Existe-t-il des plans de continuité et de reprise après sinistre en place ?
Le Bundle complet DYNAMAP en PDF à prix préférentiel : Livrables expliqués et manuel de cartographie
© Yann-Eric DEVARS - DYNAMAP. Tous droits réservés.
Nous avons besoin de votre consentement pour charger les traductions
Nous utilisons un service tiers pour traduire le contenu du site web qui peut collecter des données sur votre activité. Veuillez consulter les détails dans la politique de confidentialité et accepter le service pour voir les traductions.