Pour porter à bien un projet, il ne suffit pas d’être développeur. Il faut aussi être analyste, testeur, écrivain, administrateur, release manager et chef de projet (même si on est seul ) pour coordonner le tout.
Les quatre dernières casquettes m’occupent pour l’instant. Je suis en train d’instaurer des règles de bonnes pratiques, une liste de tâches est en place et j’ai également installé sur mon vieux serveur un serveur de build (qui compile et distribue automatiquement Phoenix sur base du dernier code source), un serveur de gestion de bugs et un serveur de test pour une gestion fine du testing. J’ai d’ailleurs remis à jour le liste des remerciements pour inclure nouveaux outils open source que j’utilise.
Pendant que j’étais en train de rédiger ma liste de choses à faire, j’ai décidé de m’y prendre autrement pour Phoenix 2: il y aura 12 pré-sorties avant de passer en version 2 et que l’application quitte son titre de “Beta“. Pourquoi douze pré-versions? Simplement parce que cette façon de faire à deux grandes qualités. D’une part, l’utilisateur plonge calmement dans Phoenix pour appréhender simplement la philosophie et les fonctionalités. D’autre part, l’utilisateur pourra se rendre compte du manque de l’une ou l’autre fonction très rapidement dans le développement. Dans le monde du logiciel, plus un changement est demandé tôt dans le développement, moins il est coûteux en temps et en effort.
Voici l’ordre dans lequel Phoenix sortira:
- Tools release.
Vérification des fonctionnalités et test des outils de Phoenix (traducteur et logeur) - Session release.
Une session c’est le point d’entrée de toutes les fonctionnalités liées à un patient particulier. - Patient manager release.
Le gestionnaire de patient permet de modifier les caractéristiques d’un patient. Certains ont demandé de stocker les informations pour calculer l’indice BMI, je les ai entendus! - Medical card manager release.
Ce module traite et gère les fiches médicales. Ce module contient entre autre, le gestionnaire de macro pour insérer du texte pré-formaté et la coloration syntaxique. - Picture manager release.
C’est le gestionnaire qui permet de lier des photos au patient. - Meeting manager release.
Le gestionnaire de rendez-vous est un agenda mais qui ne permet que de créer des rendez-vous avec la patient de la session courante. - Prescription manager release.
Ce module permet de gérer les prescriptions avec un patient. - Pathology manager release.
Le gestionnaire de pathologie permet de garder et de mettre à jour l’historique des pathologies du patient de la session courante. - Administration release.
Ici seront regroupé la gestion de toutes les informations connexes comme par exemple l’ajout-suppression-modification d’une maladie ou d’un type de maladie. - Meeting administrator release.
C’est l’autre facette de l’agenda. Ce module permettra de gérer ses rendez-vous avec n’importe quel patient sans tenir compte de la session courante. - Statistics manager release.
Étant donné que phoenix est construit sur une base de données, il est très simple d’en tirer toutes sortes de statistiques. C’est dans ce module qu’elle seront regroupées. - Traductions et pré-configuration.
Phoenix est étudié pour être multilangue mais le monde du logiciel n’a pas encore inventé d’outils pour traduite tout seul (et correctement) du texte d’une langue vers l’autre… Donc c’est mon boulot (pour l’anglais) et celui me ma douce fiancée hispanophone (qui corrigera mon espagnol qu’elle décrit comme “divino, tan lindo“, traduisez: “bourré de fautes“). Pour le néerlandais, il va falloir attendre un peu parce mon niveau n’est plus tout à fait à la hauteur 😉 D’autre part, je pré-configurerai Phoenix pour qu’il soit utilisable “out of the box“, c’est à dire tout de suite, sans passer par la case “options“.
Chaque version devra passer par 5 étapes:
- Analyse et liste des fonctionnalités.
J’arrêterai une liste des fonctionnalités que je publierai avant l’implémentation. J’écrirai également les scénarii de test à exécuter lors de la phase de debugging. - Implémentation des fonctionnalités.
C’est pour mon côté programmeur 😉 - Sortie d’une version de test.
Compilation de la version avec les options de débugging activées. - Testing.
Passage au crible de tous les scénarii de test afin de mettre en évidence les bugs qui serait toujours là. - Correction de bugs.
Cette étape est facultative si le testing n’a mis en évidence aucun bug. - Sortie de la version finale.
Mise en téléchargement de la version. Même si cette version porte le nom de “version finale“, il ne faut pas oublier que ce n’est qu’au niveau des fonctionnalités puisque Phoenix restera en version Beta tant que tout ne sera pas implémenté.