Le projet PlaniDose
Auparavant, mon entreprise développait en WinDev un logiciel destinés aux préparateurs en pharmacie. Ce logiciel fonctionnait bien mais était lent et manquait de nombreuses features. Il a donc été décidé de produire une refonte totale. Cette refonte a été développé durant ces 2 dernières années en C# sur le framework .NET
Contexte technique :
L'objectif de cette refonte était de réduire l'IHM et le nombre de click. Pour le développement de la refonte de PlaniDose nous sommes partis sur une architecture en couches dans un projet WPF en C# sur .NET 6. Nous développons sous Visual studio 2022. Nous utilisons GitHub pour la gestion de projet grâce à plusieurs tableau d'issues qui nous guident et qui nous permettent de visualiser les développements restants.
Chaque tâche est attribuée à un développeur différent et elle contient des tags du type d'ajout par exemple "Base de données" en vert.
Au niveau de l'architecture en couches, nous avons effectivement une couche de Vues en WPF (XAML) et le reste en C# sur le framework .NET 6
Situation type : (correspond aux items "analyser les objectifs et les modalités d'organisation d'un projet" et "déployer un service")
Après avoir installé cette refonte chez plusieurs clients tests, les premiers retours sont tombés, nous avons eu des réunions avec les clients en question et nous avons pu noter tous les retours. Des bugs sont remontés à nous, certaines features pouvant être améliorés et certaines manquantes. Par la suite, plusieurs autres réunions développement pour lister et attribuer les développements ont eu lieu. Le patron et le chef de projet se sont mis d'accord sur les priorités et nous on demandé d'estimer le temps de développement, le chef de projet a mis en place un diagramme avec un temps critique et nous nous sommes lancés dans les correctifs. Chacun développant sur sa branche github. Lorsqu'une features est finie nous devons passer par des tests intensifs (à la main, nous n'avons aucun système de tests unitaires ni de tests automatisés ou encore d'intégration continue même si TeamCity de JetBrain est envisagé à court terme), il faut tester tous les cas de figures, imprimer ce qui doit être imprimé et vérifier les défenses contres les injections SQL. Si aucun problème n'est répertorié, le développeur doit finir de documenter son code et de valider sa propreté avec le chef de projet et ensuite merge la branche sur le main. Une fois que chaque tâche est terminée, réunion développement pour présenter les nouveautés, mise à jour de l'exécutable présent sur le serveur distant et prise de contrôle à distance chez le client pour une mise à jour.
exemple de modification demandée par un client :
une textbox permettant de modifier en même temps la durée de toutes les prescriptions d'un patient. Nous avons donc fait le nécessaire en ajoutant dans le WPF une textbox ainsi qu'un label, côté C# nous avons mis en place du regex pour pouvoir entrer uniquement des caractères numériques et nous avons codé ce qui permet de modifier chaque objet Prescription pour modifier sa durée et sa date de fin (cf. screenshot ci-dessous).
Situation type 2 (correspond à l'item "planifier les activités"):
Dans le cadre d'un projet visant à construire une nouvelle machine nous travaillons avec un intégrateur avec qui nous avons eu l'occasion de débattre sur la technologie à utiliser ainsi que sur les moyens de communications entre sa partie et la nôtre. Dans ce cadre précis il nous a été remis un document à analyser, à débattre et à modifier si on le souhaitait.
Ces captures d'écran du document technique initial montrent qu'il est prévu de communiquer en TCP/IP sur les ports 10001 et 10002 en envoyant un fichier XML. Nous avons finalement convenu qu'il était plus simple pour nous de communiquer via des fichiers Json étant donné que notre logiciel avait déjà ses classes de traitement de Json prêtes. Le document liste aussi les commandes à développer pour synchroniser les actions entre sa partie et la nôtre.
Mon tuteur est le chef de projet, il nous assigne les tâches et organise les réunions, il valide les développements et les merge sur la main.
Grâce à GitHub notamment et à un diagramme de Gantt, le chef de projet donne les indications au patron qui va organiser ses plans commerciaux autour des développements.
Travailler sur cet énorme projet de refonte totale d'un logiciel est une véritable chance pour moi, j'ai pu apprendre des notions d'architecture logicielle, analyser les besoins des clients, apprendre à travailler en équipe autour d'un chef de projet qui donne des dates limites et des listes de tâches à accomplir, j'ai pu participer à des déploiements chez des clients et produire des documents techniques compréhensibles et clairs. L'équipe étant très petite j'ai toujours pu être à un pied d'égalité avec les autres développeurs pour partager mes idées librement et pas simplement suivre des directives. C'est une ambiance idéale au sein d'une équipe de développeur et je n'en ai été que grandi.