Rapport Final EDCampus

From air
Jump to: navigation, search


L'équipe

  • Samuel Courthial (chef de projet)
  • Sebastian Fougère
  • Robin Delbos

Supervisé par : Didier Donsez, Gérard Pollier, Anthony Geourjon (Merci à Anthony pour sa présence et ses nombreux conseils bienveillants pendant tout le projet.)

Qu'est ce qu'EDCampus?

Dashboard EDCampus

EDCampus est une plateforme de gestion de projet développé par Disrupt Campus Grenoble depuis 4 ans. Elle est actuellement en production avec 2400 comptes utilisateurs , 500 utilisateurs actifs et plus de 500 projets. Au cours de son histoire la plateforme a eu de multiples contributeurs : environ 50 étudiants + Anthony Geourjon EDCampus a été développé principalement pour que les professeurs puissent créer des projets pour leurs étudiant et pouvoir communiquer plus facilement au cours de celui-ci. Mais la plateforme regroupe de nombreuses autres fonctionnalités comme la création de sondages, un calendrier, une fonctionnalité de gestion des finances...

Plus précisément, EDCampus permet la création de projet avec lesquels il est possible d'effectuer diverses actions:

  • Création d'une hiérarchie en créant des sous-projets, rattachés à un parent. Ces projets peuvent alors partager certaines ressources.
  • Partage de dossiers, fichiers et liens externes.
  • Création de tâches, pouvant être manipuler et organiser dans des Kanban ou des Gantt.
  • Suivi de l'évolution d'un projet depuis le calendrier. Ce dernier répertorie tous les évènements passés et futurs, a propos d'un ou plusieurs projets suivis.
  • Organisation d'atelier (Brain-storming, tableau blanc, visio, Business Model, Lean et SWOT Canvas).
  • Gestion des ressources (nom, quantité, prix).
  • Sondages.
  • Création de publications (si le projet est publique, naturellement).
  • Gestion des contacts liés au projet.
  • Gestion de la finance du projet.
  • Demande de livrable, auprés des membres du projet.

Notre objectif au cours de ce projet était de contribuer à EDCampus par de la correction de bugs et de l'ajout de fonctionnalités, ainsi que par la refactorisation d'un chat.

Architecture du système

Architecture générale


Nous voyons donc que l'architecture est plutôt classique avec une partie front, une partie back et une base de données. Cependant il y a également une deuxième partie back-node utilisée pour la fonctionnalité de chat. Cette partie contient le serveur SocketIO qui permet d'informer les utilisateurs lors d'envoi de message. Ce serveur gère des salles pour chaque discussions qu'il est possible de rejoindre pour être notifié quand un message est envoyé. Le serveur ne contient ni les discussions, ni les messages envoyés, qui doivent ensuite être récupérés côté client en allant les chercher dans la BDD.

Technologies et outils

Technologies

  • PHP : technologie utilisée pour le BackEnd
  • AngularJS : technologie utilisée pour le FrontEnd
  • SQL : technologie utilisée pour la base de données
  • SocketIO : technologie utilisée pour le chat
    • Il s'agit d'une bibliothèque JavaScript permettant une communication bidirectionnelle temps réel entre les clients et les serveurs. Cette bibliothèque facilite l'envoi et la réception d'évènement de différents type, de contenu varié. De plus, Socket.io permet facilement la création de "salles", des canaux pouvant être rejoint ou quitter par des sockets. Elles permettent notamment l'envoi de messages à un sous-ensemble précis de client (ceux ayant rejoint la même salle).
Le concept de "salles" de socket.io

Outils

  • GitLab : Plateforme pour le travail collaboratif
  • GitKraken : Outil pour utiliser Git plus facilement
  • PHPStorm : Editeur pour le developpement BackEnd
  • WebStorm : Editeur pour le developpement FrontEnd
  • MySQL : Outil pour accéder a la base de données
  • Docker : Outil d'empaquetage d'une application et de ces dépendances

Réalisations techniques

Correction de bugs

Une issue de test et de correction de bug

Nous avions plusieurs types d'issues de correction de bugs

  • Traduction manquante
  • Erreurs d'affichage
  • Fonctionnalités ne se comportant pas de la bonne façon

Ajout de fonctionnalités

  • Envoi de notifications aux utilisateurs
  • Ajout d'un bouton de suppression
  • Affichage des prochaines échéances dans un projet

Ajout du chat

Le chat d'EDCampus était déjà présent mais de nombreuses fonctionnalités ne fonctionnaient pas correctement. Notre objectif était donc de débuguer les fonctionnalités déjà présentes, tout en effectuant une refonte du chat en remplaçant Firebase (l'outil hébergeant le serveur de chat) par socket.io. L'intérêt de cela était de pouvoir se libérer de l'utilisation d'un service tier dans EDCampus, en hébergeant soi-même le chat. L'ensemble des discussions et messages était déjà stocké dans la BDD. L'idée était donc d'utiliser socket.io pour créer un serveur de notification, informant les clients lors de la réception et de l'envoi d'un message.

Organisation

Méthode

Nous avons travaillé en méthodologie agile avec GitLab. Nous avons repartis notre travail en sprints d'une semaine chacun pour un total de 6 sprints. A chaque sprint nous organisions au moins une réunion le lundi matin avec Anthony Geourjon afin de s'organiser pour la semaine et faire un récapitulatif de la semaine précédente. Pendant chaque sprint nous avions des issues données par Anthony Geourjon que nous nous répartitions selon nos préférence et notre avancement.

Le contenu

Organisation de nos issues

Notre travail s'organisait en deux parties :

  • Dans les 4 premiers sprints nous avons travaillé sur de la correction de bugs et de l'ajout de fonctionnalités, choisies chaque semaine par Anthony Geourjon.
    • L'idée était de commencer par des issues faciles pour se familiariser avec le code et sa structure avant de se lancer dans la refonte du chat. Ces quelques semaines nous ont permis de rapidement monter en compétences.
  • Dans les 2 derniers sprints nous avons travaillé sur la fonctionnalité de chat.

Rôles

  • Dans la première partie nous choisissions les issues selon nos préférences, certaines issues nécessitaient doc des modifications coté front et back, Nous avions donc tous un rôle de développeur FullStack.
  • Dans la deuxième partie Samuel travaillait sur SocketIO alors que Robin et Sebastian travaillaient sur des issues d'ajout de fonctionnalités du chat et de la correction de bugs des fonctionnalités existantes. Puis une fois les fonctionnalités ajoutées nous avons tous travaillés sur l'intégration de SocketIO et sur les tests.


Métriques

Répartition du travail

Nous avons réalisés des métriques sur le nombre de lignes de code ainsi que sur le nombre d'issues; Cependant celles ci ne sont pas forcement représentatives puisque certaines issues nécessitaient plus de travail que d'autres sans forcement nécessiter plus de code.

  • Nombre d'issues : 33 issues au total
    • Robin Delbos : 24.2%
    • Samuel Courthial : 39.4%
    • Sebastian Fougere : 36.4%
  • Lignes de code : 930 lignes au total
    • Robin Delbos : 16.0%
    • Samuel Courthial : 48.9%
    • Sebastian Fougere : 35.1%

Coût développeur

Nous avons calculé à partir d'un salaire annuel de 26000€ (soit 26000*1.45=37700€ avec les charges patronales) et de 235 jour par an, un coût journalier de 37 700/235 = 160€ par jour Nous avons travaillé 22 jours à 7h par jour, ce qui nous donne finalement un coût total de 10 560€ pour toute l'équipe pendant notre projet.

Cocomo EDCampus

Le modèle COCOMO permet d'estimer l'effort à fournir et la durée d'un projet afin d'éviter les erreurs de budgets et les retard de livraisons. Sur notre graphique COCOMO ci dessus, on peut voir que notre contribution, qui correspond à 930 lignes de codes écrites, nous donne un effort de 2.766 qui correspond au nombre de mois qu'il faudrait pour qu'un seul développeur fasse ce même travail. Il est aussi indiqué que pour ce projet, le modèle COCOMO nous suggère d'être seulement 0.775 personne (colonne STAFFING), soit une personne à 3/4 temps, et que si c'était le cas, cette contribution au projet EDCampus prendrait 3.569 mois (colonne DURATION). Or, nous sommes 3 pour ce projet donc cela nous donne un effort de 2.766/3 = 0.922 mois de travail par personne ce qui est sensiblement le temps que nous avons consacré à ce projet puisqu'il est de 22 jours.

Conclusion

Finalement le projet était enrichissant nous avons pu travailler sur un projet concret et même avoir des retours d'utilisateur sur notre travail. De plus nous avons eu l'occasion de travailler sur des fonctionnalités front et back avec des langages que nous n'avions que peu utilisé jusqu'à présent.

Cependant le projet manque de documentation. De plus le projet ayant eu de nombreux contributeurs il est parfois compliqué de comprendre comment fonctionne le code avec toute les façons différentes de coder.

Glossaire

Bug : Défaut de conception d'un programme informatique à l'origine d'un dysfonctionnement.

Back/BackEnd : Partie d'un système avec laquelle un utilisateur n'interagis pas directement.

Chat : Fenêtre de discussion.

Front/FrontEnd : Partie d'un système avec laquelle un utilisateur interagis.

Fullstack : Un développeur fullstack travaille sur toute les parties du système.

Git : Git est un logiciel de gestion de versions décentralisé.

Issue : Tâche à réaliser lors d’un sprint.

Refactorisation : réécriture d'un programme pour l’améliorer.

Sprint : Période de travail définie avec un certain nombre d'issues.

Bibliographie

EDCampus

Gitlab EDCampus

Fiche de suivi

Flyer

Poster

Pitch

Présentation finale