Organisation et structure de Projet

Maintenant que le projet est introduit, que les motivations sont expliquées, on va pouvoir commencer à entrer dans le vif du sujet.

Avoir un langage commun : UML

Etant donné la nature Open Source du projet et qu’à terme j’aimerais pouvoir accueillir des contributions de manière sereine, je pense qu’il est important d’installer des bases solides d’organisation. Cela permettra à tout le monde d’être sur la même longueur d’onde.

Pour cela je voudrais maximiser l’utilisation du langage UML (Unified Modeling Language) et du Processus Unifié

L’important pour moi la dedans est de pouvoir intégrer un processus de développement structuré en différentes phases. Mais également de permettre à tout un chacun, surtout les non développeurs qui n’y connaissent rien en code, de pouvoir suivre l’évolution du développement en ayant un support lisible et compréhensible pour eux.

UML est un langage schématique que n’importe qui peut facilement apprendre et comprendre et il peut être utilisé dans tous les domaines, même ceux n’ayant rien avoir avec l’informatique.

Le Processus Unifié comprend 4 phases distinctes :

  1. La Phase d’Inception, consiste à évaluer le projet, on y détermine des cas d’utilisation et un premier brouillon d’architecture.
    On modélise les processus métier et on gère les exigences du projet.
  2. La Phase d’Élaboration, consiste à construire l’architecture du système. En fin de cette phase on doit connaître les exigences du projet de manière définitive.
    Dans cette phase on gère les exigences du projet, on analyse et on conceptualise.
  3. La Phase de Construction, consiste au développement logiciel de l’architecture de notre programme qu’on a défini pendant la phase d’élaboration.
    Principalement on analyse, on développe, on implémente et on test.
  4. La Phase de Transition, consiste à déployer l’application et à former l’utilisateur.

Le Processus Unifié divise le projet en une multitude d’itérations afin de ne pas avoir à gérer un projet trop énorme d’une seule traite. En gros chaque itération représente un projet dans le projet et chaque itération peut elle même être divisée en différentes itération si le besoin s’en fait sentir.

Chaque itération est parcourue par les 4 phases du processus unifié, cela nous donne un chemin simple à suivre avec des étapes bien précises qui dit qui fait quoi et quand.
Une fois toutes les itérations effectuées, le projet est fini et livrable.

Le Processus Unifié me permettra de savoir où j’en suis, quel est le travail à faire et quelle sera la prochaine étape.
Enfin UML me permettra d’avoir un langage commun avec ceux et celles qui suivent le projet et qui auront envie de prendre le temps d’apprendre le langage (ou qui le connaissent déjà d’ailleurs).

Organiser les échanges d’idées et de code avec les Design Pattern :

Certain(e)s d’entre vous sont des développeur/euses et vous m’avez déjà même proposé de pouvoir contribuer au projet en fournissant des idées ou même des portions de code.

L’échange d’idée sera évidemment encouragé, ça c’est certains. Surtout que je ne suis pas un Trader vraiment acharné, je n’ai certainement pas la science infuse. Il sera donc très intéressant d’avoir des idées venant de Trader confirmé par exemple.

L’échange de code sera au début restreint, par exemple si vous remarquez un ou plusieurs bug, des erreurs d’algorithme ou autre. Restreint parce que j’aimerais pouvoir fournir une base de travail commune solide, mettre ça en place à plusieurs ça peut vite être compliqué quand on est pas habitué à gérer un projet informatique de bout en bout.

Donc pour encourager le partage de code, il faut également qu’on puisse être sur la même longueur d’onde et moi le premier.
Je vais donc maximiser l’utilisation de Design Pattern connus. Ils sont très bien documentés et ont l’avantage d’avoir été éprouvés. Ils pourront apporter je pense régulièrement des solutions élégantes pendant le développement.

Connaître et intégrer les Design permet de parler d’une partie de code sans devoir connaître l’intégralité de l’algorithme et devoir le décrire en entier.
Cela devrait alléger les discussions.

Voilà, c’était un article plus court pour aujourd’hui car je travail d’ors et déjà sur les premier schéma UML et la division du projet en plusieurs premiere grosses itérations que je détaillerai dans un futur article.

J’espère que la lecture vous aura plu, n’hésitez pas évidemment à mettre un commentaire si vous le voulez 😉

PS : Voici quelques sources d’apprentissage pour ceux/celles qui en ont envie :

UML

Cours OpenClassRoom sur UML : https://openclassrooms.com/fr/courses/2035826-debutez-l-analyse-logicielle-avec-uml

Livre – “UML 2.5” aux édition ENI :
https://www.editions-eni.fr/livre/uml-2-5-initiation-exemples-et-exercices-corriges-5e-edition-9782409024085

J’utilise principalement ce bouquin pour apprendre progressivement l’UML (j’ai la 4ème édition par contre).

Design Patterns

Livre – “Design Patterns en Java” aux édition ENI :
https://www.editions-eni.fr/livre/design-patterns-en-java-les-23-modeles-de-conception-descriptions-et-solutions-illustrees-en-uml-2-et-java-4e-edition-9782409012815

Site web : Refactoring.Guru
https://refactoring.guru/ 

(A voir absolument, explique bien et est bien illustré, très agréable à lire)

Site web : Geek for Geeks
https://www.geeksforgeeks.org/python-design-patterns/

Site Web : Tutorial Point :
https://www.tutorialspoint.com/python_design_patterns/index.htm