Rapport d'analyse

Le rapport d’analyse doit refléter votre compréhension du projet: - à quoi sert l’application, ses composantes principales dont certains seront candidats pour les tests automatisés, pipelines MLOps. - l’architecture, le stack technologique, la structure du fichier - l’analyse de comment le projet est dockerisé (la base de données est stockée où dans un volume, un bind mount? quels services sont déployés?) - l’analyse du pipeline CI/CD existants, des éventuels tests automatiques - le processus d’installation (le readme.MD) - hygiène, qualité de la structure du projet, du code.

Vous pouvez aussi inclure:

• un (ou des diagrammes) diagramme avec les parties principales de l’app que vous avez pu identifier et à quoi elles servent (les règles et les alarmes? le système de vote (Sur quoi? par quoi)?, les stats, la gestion des groupes, les flashnews (c quoi? et ça se base sur quelques autres sous-parties)…) avec une description claire de chacune. Cela vous permettra par la suite de vous dire, ok notre groupe va se concentrer sur la réalisation de tests unitaires et d’intégration pour le système de vote ou sur la gestion des règles (les alarmes ont-elles effectivement enclenchées selon les paramètres choisies dans les règles?)

• Audit thématique: Incluez pour chaque aspect du cours, ce que vous avez pu observer jusque-là:

  • e.g. sécurité: y-a-t-il des manquements que vous avez déjà pu remarquer? (Sachant que l’audit approfondi et les pistes d’amélioration seront abordées de manière plus systématique après l’intervention de Michael?
  • tests automatiques: y en a t-il ? quelles parties en sont concernés?
  • n’amenez pas encore des solutions par thème, ceci sera fait de manière progressive après chaque intervention, un constat de ce que vous avez déjà pu souligner suffit à ce stade.

Ne me soumettez pas de longs rapport. Visez une documentation concise et clair.