Agnan Diane Sigaud Vincent Charlois Nils. Rapport final : Plateforme de gestion de projets

Transcription

1 Agnan Diane Sigaud Vincent Charlois Nils Rapport final : Plateforme de gestion de projets 1

2 SOMMAIRE I Présentation du projet... 3 I 1) Contexte universitaire... 3 I 2) Reprise de l'ancien projet... 3 I 3) Outils utilisés, pourquoi... 5 II Le projet II 1) MCD...10 II 2) Coeur du projet...14 L'identification du visiteur...14 Les droits...15 Les modules...16 III Stratégie de répartition du travail IV Difficultés rencontrées IV) 1) Humaine...23 IV 1) a) Les Réunions :...23 IV 1) b) Vie du groupe :...23 IV 2) Matériel...24 IV 2) a) Développement :...24 IV 2) b) Portage :...25 V Guide d'installation de la Plateforme V 1) Pré-requis...26 V 1) a) Serveur apache...26 V 2) Base de données...27 V 3) Les dossiers...28 V Développer avec Symfony V 1) Le premier module...28 VI Les commandes Symfony VI 1) Génération de la structure...29 VI 2) Les namespaces...29 VI 2) a) Doctrine...29 VI 2) b) Generate...31 VI 2) b) Configure...31 VII) Conclusion VIII) Remerciement

3 I Présentation du projet I 1) Contexte universitaire Notre projet consistait à reprendre la plateforme de gestion de projets déjà existante afin de la mettre en exploitation pour qu'elle soit utilisable les prochaines années. Cette application est un outil indispensable à la demande, l'attribution des projets et des comptes rendus pour les deux années de Master au sein du Centre d'enseignement et de Recherche Informatique d'avignon. A l'heure actuelle, les membres administratifs ne possèdent qu'une version très dégradée de cette Plateforme : Création et injection des données en ligne de commande dans la base de données PostgreSQL. Insertion du code php à la main Insertion du code html dans la base de donnée afin qu'elle soit affiché correctement dans la plateforme comme la fonctionnalité du calendrier. Dans un premier temps nous avons du réaliser un audit de cette plateforme afin de faire un état des lieux des fonctionnalités implémentées ou non, pour pouvoir attaquer au mieux la reprise de ce projet. Cet audit s'est avéré très révélateur aux vues du très grand nombre de fonctionnalités défectueuses qui ont été développées dans le cahier des charges du premier semestre (voir ci-après). I 2) Reprise de l'ancien projet Une précédente plateforme avait été développée 2 ans auparavant avec le framework Zend, n'ayant aucune formation dessus, nous avons du apprendre "sur le tas". Une étape indispensable afin d'étudier cette plateforme a bien sur été son installation, qui a été la partie la plus complexe à réaliser! Très peu, voire aucune documentation n'avait été laissée par le groupe précédent pour cette installation, il nous a donc fallut un certain temps avant d'y parvenir correctement (installation qui avait été réalisée par Julien Ginoux). Une fois l'installation terminée, un autre problème s'est présenté : la gestion des droits par le C.A.S. (Central Authentification Service). En effet, il nous était impossible de nous connecter au LDAP via le CAS et donc l'ensemble des fonctionnalités nous étaient inaccessibles. Il nous a donc fallut contourner ce problème de connexion afin d'enlever cette vérification de droits. Nous avons donc commencé par tester une à une les fonctionnalités présentes afin de juger la quantité de travail à apporter. 3

4 Au fur et à mesure de l'avancée de nos tests, nous nous sommes rendus compte qu'une très grande majorité des fonctionnalités soit disant en place, ne l'étaient pas du tout, même celles qui sont indispensables (ajout/modification/suppression de sujets-groupes). Pourtant après nous être "plongé" dans le code, ces fonctionnalités semblaient implémentées, mais visiblement pas fonctionnelles. Toutes ces complications rencontrées vous ont été présentées lors de notre précédent cahier des charges. A la fin de cet audit, trois choix se présentaient à nous : Reprendre l'actuelle plateforme sous Zend et la corriger Redévelopper entièrement la plateforme sous Zend La redévelopper sous un autre Framework Ayant eu de très grosses difficultés pour installer et tester la plateforme (insertions de beaucoup de données en ligne de commande SQL), nous en avons déduis qu'il serait largement préférable de tout simplement re-coder complètement la plateforme, car la corriger aurait été réellement contraignant et une perte de temps significative se serait fait sentir. La reprise du projet en utilisant Zend nous a paru relativement complexe. En effet, Zend n'imposant pas de convention de codage, les sources de la plateforme était trop peu structurées. La possibilité de travailler à plusieurs sur de tels codes était alors difficile à mettre en place. Après plusieurs réunions, nous avons préféré tout refaire. Nous avons donc pris la décision de re-coder entièrement la plateforme. Cependant, il nous fallait un outil permettant de développer rapidement et proprement une application web. Nous avons donc recherché un outil adapté, puissant et facile à utiliser. Notre choix s'est porté sur le Framework Symfony, qui semblait répondre à nos attentes De plus, Symfony est actuellement utilisé par les développeurs du CRI ( des applications web telles que FileZ et RdvZ ont été développées avec Symfony ) et permettrait une harmonisation du système d'information. Après une étude sur ce framework, nous l'avons choisi pour sa puissance, sa rigueur et sa communauté ( grandissante ). Ainsi, avec cet outil, nous avons pu rapidement développer une plateforme, certes pas complète, mais entièrement opérationnelle. 4

5 I 3) Outils utilisés, pourquoi Suite à plusieurs réunions, nous avons donc décidé de changer de Framework pour prendre Symfony. Pourquoi ce choix? 4 environnements : Dans un premier temps, il faut savoir que Symfony dispose de quatre environnements Environnement de développement : Environement utilisé par les développeurs web lors du développement des applications pour en ajouter de nouvelles, corriger les bugs,... Environnement de test : Environnement qui teste automatiquement les applications. Environnement de qualité : Environnement qui permet aux utilisateurs de tester l'application et d'envoyer des rapports de bug Environnement de production : Environnement final de l'utilisation de la plateforme. Automatisation : Symfony utilise certaines lignes de commande pour automatiser certaines tâches, comme par exemple générer les modèles, vues et contrôleur pour créer de nouveaux modules. Ces lignes de commandes sont issues du shell de Linux, qui permet à l'utilisateur de ne pas être dépaysé. La liste de ces commandes sera donnée plus bas. Base de données : Symfony permet d'utiliser n'importe quel gestionnaire de base de données, Zend-Db compris et aussi de gérer la BDD de façon abstraite avec sfdatabase. sfpostgresqldatabase permet d'effectuer les connexions et déconnexions au base de données PostgreSQL. La configuration de la connexion à une base de données est vraiment très facile, elle utilise une ligne de commande Symfony (on en revient à l'automatisation) : "php symfony configure:database "type_base_de_données(ex: pgsql ou mysql):host=serveur_hote;dbname=nom_base_de_données" login password Ce qui pourrait nous donner : $ php symfony configure:database "pgsql:host=grumly.univavignon.fr;dbname=plateforme" login_plateforme pw_plateforme Une deuxième commande va permettre de générer le schéma de la base de données utilisée (relation entre les tables, clé étrangères, contraintes...) : $php symfony doctrine:build-schema L'architecture : Symfony respectait toutes les demandes techniques de notre cahier des charges : Programmation Full Objet ( PHP5 ) Implémentation du modèle MVC. Gestion de Système de Gestion de Base de Données PostgreSQL. 5

6 Abstraction des requêtes SQL. Gestion des plugins aisée ( un dossier plugins, un fichier activant les plugins ) pour inclure le plugin LDAP. Configuration intelligente qui s'adapte à tous les servers et qui permet une installation facilisé et rapide. Génération de code par commande qui diminue considérablement la durée de développement. Prise en main facilitée par un tutoriel officiel présent sur le site de Symfony ( voir capture d'écran ) qui nous as permis de mettre le framework en place. Une grande documentation en ligne pour la prochaines équipe qui décidera de continuer son développement. Architecture des fichiers : L'architecture des fichiers de Zend n'est pas favorable à la reprise de projet. En effet toutes les fonctionnalités sont comprises dans un seul fichier (Un fichier User pour gérer les droits par exemple). Ces fichiers sont très long et ne sont pas scindé par sous fonctionnalités (CRUD : Create, Read, Update, Delete par exemple). De plus il n'existe pas de convention de codage. Ces longs fichiers sont difficilement lisibles. Dans le cadre de ce projet qui est amené à être modifié tout les ans, l'adaptation au code peut prendre beaucoup de temps. De plus, toutes les parties et fonctions de ces longues lignes de codes sont interdépendantes, ce qui pose problème pour modifier une fonction ou opérer des maintenances ponctuelles. Symfony permettrait d'harmoniser le code de chacun en un seul modèle et une implémentation dans une structure bien définie. 6

7 Sa structure de fichier "Une fonctionnalité = un module" dans lequel toutes les fonctionnalités et les templates associés sont séparés permet de trouver rapidement la fonctionnalité et la fonction désirée (exemple : la création dans le module sujet). Vues et controlleurs : Mise en page : Un fichier par défaut présentant un affichage de base (template) est présent dans le dossier apps/nom_application/templates/ et s'appelle layout.php Les helpers facilitent grandement la tache, c'est une sorte de bibliothèque permettant d'écrire rapidement du code HTML en passant par des accélérateurs PHP. Les fichiers css sont présents dans le dossier web/css, les images dans web/images et les javascripts dans web/js Toutes les classes (automatiquement générées par symfony) seront présentes dans le dossier lib, qui contiendra entre autres deux sous dossiers form, qui contiendra l'ensemble des classes définissant les formulaires, et model qui va contenir l'ensemble des propriétés de chaque table (un champ est il obligatoire? De quel type est-il? Peut-il être nul? etc...) Modules : Une des caractéristiques très intéressante à Symfony, est l'utilisation de modules. Un module est un ensemble autonome de code PHP qui représente une caractéristique de l'application (le module API par exemple), ou un ensemble de manipulations, l'utilisateur peut le faire sur un modèle d'objet (cela peut être un module qui gère des rapports d'étudiants par exemple) : $php symfony doctrine:generate-module --with-show --non-verbose-templates nom_de_l'application nom_du_module nom_du_modèle Cette commande crée un module, pour l'application nom_de_l'application en s'appuyant sur le modèle nom_du_modèle. Un nouveau répertoire est alors créé à cet emplacement : apps/frontend/modules/ nom_du_nouveau_module/ Et il contient 2 dossiers qui sont actions et templates : - le fichier actions/actions.class.php permet à l'utilisateur d'avoir accès aux actions de base sur un enregistrement : le CRUD (CRUD : Create Read Update Delete sont les 4 opérations de base que l'on peut effectuer sur une table) - le dossier templates va contenir, comme son nom l'indique, tous les templates, les "vues" de notre module, à savoir les divers formulaires du CRUD (Index, new, edit, show, la suppression n'étant qu'un lien présent sur la fiche d'un élément) 7

8 Ainsi nous avons donc décidé de développer la plateforme en utilisant ce Framework. Cependant, nous avons gardé les mêmes comportements au niveau graphique (design, ergonomie) et au niveau du fonctionnement (scénarios). Opération ZEND SYMFONY Création de Modele/Vue/ Contrôleur Module de Test Création de chacun à la main. Création à la main Une ligne de commande permet de les générer automatiquement. Un environnement de Test déjà implémenté Module de bug report Création à la main Un environnement appelé "Stagging" qui permet aux utilisateurs de tester l'application et d'envoyer des rapport de malfonctions ("Bug report"). Génération de code Presque inexistante Très présente Hiérarchie de dossiers Très flexible (doit tout paramétrer) Très stricte mais très propre Plugins Inexistants Large gamme (dont le plugin Zend) Base de données Modele "ActiveRecord" Choix par l'utilisateur TABLEAU Tableau : Comparatif Zend/Symfony Création MVC : Sur Zend il faut déjà connaître les base du MVC pour comprendre et développer sur la plateforme. 8

9 Mise en place des tests : Pendant le développement, il faut mettre en place des tests unitaires et fonctionnels. Nous nous sommes basés sur les différents documents de l'ancienne équipe afin de prévoir un plan de test. Lors de l'installation de la plateforme nous avons du tester toutes les fonctionnalités : Nous avons regardé dans le code si les fonctionnalités étaient implémentées. Nous avons notifié si nous pouvions les tester. Nous avons conclu si elles étaient fonctionnelles. Nous avons detérminée si elles étaient à améliorer ou pas. La plupart des fonctionnalités implémentées n'étaient pas opérationnelles comme en témoigne le tableaux des tests des fonctionnalités en annexe. Test Unitaires : Pour implémenter les tests unitaires, le framework Zend a besoin d'un Framework : PHPUnit, alors qu'ils sont implémentés de base sur Symfony. Sur Symfony il existe un dossier test qui contient deux dossiers : Le dossier Boostrap : il contient deux fichiers. functional.php et unit.php. Ils sont à inclure au début de chacun de vos tests et permettent d instancier l environnement. Le dossier Unit : il permet de créer ses fichiers de test. Un Framework étant long et toujours complexe à installer, la solution Symfony permet un gain de temps considérable pour les test Unitaires. Test Fonctionnels : Nous avons cependant pu effectuer des tests fonctionnels de l'ancien projet ( développé avec Zend ). Notre analyse a porté sur la vérification de l'implémentation des fonctionnalités et leur bon fonctionnement. Pour cela, nous nous sommes basés sur les rapports et autre documents de l'ancienne équipe. Un tableau répertoriant les différentes fonctionnalités testées et les résultats de ces essais est présent en fin de rapport. L'élaboration de ce tableau fut laborieux car nous avons du réaliser tout nos tests fonctionnelles à la main. Sous Symfony, la possibilité d'effectuer des tests fonctionnels est implémentée par défaut dans le framework. Le Dossier test/functional : il contient categoryactionstest.php.qui crée automatiquement un fichier de test fonctionnel de base. La classe sftestfunctional fournis les méthodes des tests. Au vu de toutes les fonctionnalités défaillantes, c'est ce qui nous a poussé une fois de plus à développer à nouveau tout le projet. Et grâce à la facilité et la rapidité de Symfony, nous pensons que notre décision a été judicieuse. 9

10 II Le projet II 1) MCD Avant de développer une application, il faut définir une structure de stockage des données. Il faut être très vigilant pour la réalisation de cette structure car tout le projet repose sur celle-ci. Nous avons créé plus de 5 versions différentes du MCD. Ce travail s'est étalé sur 3 mois. Nous vous présentons ici la dernière version. Modèle Conceptuel de Données Théorique Il est à noté que nous avons du l'adapter au framework Symfony lors de l'implémentation. Pour respecter l'accès aux données par le framwork, nous avons du modifier le MCD comme suis : 10

11 Modèle Conceptuel de Données actuellement implémenté Nous allons détailler maintenant ce graphique : Nom Rôle Tables jointes Raisons personnel_ldap Lors de la connexion d'un utilisateur à la plateforme, celui-ci est automatiquement inséré dans cette table et ce afin de pouvoir gérer les archives des projets dès lors que les étudiants quittent le CERI. Elle stocke le l'id autoincrémenté, le numéro uapv(uid), le mail, le nom, le prénom ainsi que le statut extrait du LDAP sujet_tuteur, sujet_personnel, groupe_etd, compte_rendu La table personnel LDAP est le centre d'acquisition des ressources des utilisateurs, aussi bien professeurs qu'étudiants, ce qui explique le nombre conséquent de jointures. sujet_tuteur Cette table stocke l'id du sujet ainsi que l'id de personnel_ldap du tuteur ainsi qu'un booléen pour personnel_ldap, sujet Cette table est dite "intermédiaire", car un tuteur peut être 11

12 sujet_personnel sujet sujet_thematique thematique groupe_etd groupe reunion_inter indiquer s'il est le tuteur princpal du sujet ou non. Cette table stocke l'id du sujet et l'id du personnel_ldap. Cette table stocke l'id, le titre, la description du sujet ainsi que le nombre d'étudiants maximum et minimum d'étudiant, l'année de Master, l'année scolaire, si il est clôture ou pas, des liens internet ainsi que le nombre de places de libres pour l'inscription Cette table stocke l'id du sujet ainsi que l'id thématique Cette table stocke l'id et le nom de la thématique Cette table permet de stocker l'id de l'étudiant ainsi que l'id du groupe Cette table stocke l'id du groupe, l'id du sujet, sa date de création, un booléen qui indique la validation du groupe Cette table stocke l'id du groupe, le semestre de la réunion, la date, l'heure, la personnel_ldap, sujet sujet_thematique, sujet_tuteur, sujet_personnel, groupe sujet, thematique sujet_thematique personnel_ldap, groupe sujet, reunion_inter, reunion; groupe_etd, groupe_tuteur, compte_rendu groupe associé à plusieurs sujet. Cette table est dite "intermédiaire", elle stocke l'id de la personne ayant créé le sujet ( l'auteur ). Cette table permet de stocker toutes les informations concernant le sujet de projet. Cette table est dite "intermédiaire", car un sujet peut être associé à plusieurs thématique. Cette table permet de donner des thématiques aux sujets afin que les étudiants puissent faire leur choix selon leur orientation future. Cette table est dite "intermédiaire", un groupe peut contenir plusieurs étudiants. Cette table permet de stocker les groupes d'étudiants qui sont associés aux différents sujets. Si le booléen est à false, il est considéré comme un groupe temporaire, le simple fait de le mettre à true valide le groupe. Cette table permet aux responsables administratifs de 12

13 reunion compte_rendu calendrier faq parametre notation et les commentaires éventuels Cette table stocke l'id de réunion, l'id du groupe ainsi que la date de réunion Cette table stocke l'id du compte rendu,l'id du groupe, la date de réunion butoire, sa date de création, l'id du calendrier, les personnes présentes, points abordés, travail réalisé, travail à réaliser, la date de la prochaine réunion, s'il a été validé ou pas, par qui il a été validé (uid) et la date de validation. Cette table stocke l'id du calendrier, le semestre, l'intitulé et la date butoir (utilisé pour les comptes rendus). Cette table stocke l'id de la FAQ, les questions ainsi que les réponse Cette table stocke l'id du paramètre, son nom et sa valeur groupe groupe, calendrier, personnel ldap compte_rendu X X gérer les réunions intermédiaires ainsi que les notations et les commentaires associés au groupe, à développer à posteriori. Cette table permet aux responsables administratifs et aux étudiants de gérer les dates de leurs les réunions de groupe, à développer a posteriori. Cette table va permettre aux étudiants de rédiger leur compte rendus et aux tuteurs la validation de ces rapports. Cette table va permettre aux membres administratifs ainsi qu'aux tuteurs de gérer le calendrier par semestre et leur permettre de voir si les comptes rendus ont été délivrés à temps Cette table ne sert que de stockage à la FAQ. Cette table de stockage permet de gérer les différentes configurations pour la plateforme (server LDAP, Répertoire de stockage ect..) 13

14 II 2) Coeur du projet Le projet a été divisé en plusieurs sous parties afin de répartir les taches au sein du groupe. Nous avons pu identifier plusieurs parties essentielles qui constituent le coeur du projet : L'identification de la personne connectée La gestion des droits et des profils Les fonctionnalités A cela s'ajoute les notions de design et d'ergonomie, pour ce faire nous avons utilisé les précédents fichiers de style. Ils respectent la charte graphique du site de l'université d'avignon. L'identification du visiteur Un utilisateur se connecte via l'annuaire LDAP en passant par une authentification en utilisant le serveur CAS. (" CAS est un système d'authentification unique : on s'authentifie sur un site Web, et on est alors authentifié sur tous les sites Web qui utilisent le même serveur CAS. ") Une fois connecté, nous pouvons accéder à des informations personnelles stockées par le LDAP ( uidnumber, statut, nom, prénom, mail... ) Grâce à ces informations, nous avons pu définir des statuts et leur attribuer des actions, voici quelques exemples : Le CAS lié au LDAP inclus dans la plateforme 14

15 Action Statut de l'acteur Assigner des tuteurs à des sujets Valider des groupes temporaires avec un seul étudiant Modifier les paramètres de la plateforme Administrateur Administrateur Administrateur Valider un groupe temporaire Modifier un groupe définitif Valider un compte rendu Tuteur Tuteur Tuteur Créer un compte rendu Créer un groupe temporaire Rejoindre un groupe temporaire Etudiant Etudiant Etudiant Les droits Ils sont gérés via des Credentials ( ). Dans le LDAP, un champ ( edupersonaffiliation ) permet d'obtenir le statut de la personne connectée ( étudiant ou autre ). Certaines personnes ayant le statut administrateur, nous avons utilisé leur identifiant uapv afin de les distinguer. 3 niveaux sont gérés : administrateur tuteur ( principal et secondaire ) étudiant Nous avons par ailleurs créé un menu pour chacun de ces profils. Nous pouvons distinguer 2 types de modules : ceux basés sur des modèles et dont les opérations de bases sont déjà implémentées ( CRUD ) ( on les appellera module-crud dans le rapport ) ceux qui ne sont pas basés sur un modèle ( c'est le cas pour la gestion des tables intermédiaires ) 15

16 Les modules Afin de répondre au cahier des charges, nous avons utilisé la notion de modules. Chaque module est un dossier dans lequel sont présents au moins 2 répertoires : actions et templates. Voici la liste des modules que nous avons développé avec leur fonctionnement au sein de la plateforme. faq : Ce module gère la liste des questions/réponses, celle ci est consultable par tout visiteur ( connecté ou pas ) et est accessible par une entrée dans le menu. Seul l'administrateur peut rajouter une question/réponse. Voici les champs de la table faq : id question reponse Affichage de la FAQ 16

17 sujet : Les sujets sont gérés par ce module, ils sont également consultables par un simple visiteur. Seul les administrateurs peuvent créer un sujet, puis un tuteur principal est assigné à un sujet. Afin de respecter notre cahier des charges, nous avons implémenter la notion de thématiques, pour ce faire, nous proposons à l'administrateur d'associer le sujet à plusieurs thématiques lors de la création de celui ci. Lorsque des étudiants connectés sur la plateforme consultent un sujet, ils ont la possibilité de le rejoindre. Affichage des sujets 17

18 Création de sujet (Admin) 18

19 Association des thématiques lors de la création de sujet (Admin) compte_rendu : Après chaque réunion qu'un groupe d'étudiants effectuera avec son (ses) tuteur(s), il aura pour obligation de remplir et d'envoyer un compte rendu de cette réunion, avant la date butoire, en prenant bien soin de renseigner les informations suivantes : Date de la réunion Date butoire correspondante Personnes présentes Points abordés Travail réalisé Travail à réaliser Date de la prochaine réunion (si connue) Comment se déroule la création d'un compte rendu sur la plateforme? La création d'un compte rendu par un étudiant jusqu'à sa validation par un tuteur va se dérouler en plusieurs étapes. Dans un premier, en début de semestre un administrateur devra rentrer toutes les dates limites de rendu d'un compte rendu pour le semestre (ex : 1er compte rendu à rendre avant le 10 octobre, 2ème à rendre avant le 2 novembre etc...) grâce à un module prévu à cet 19

20 effet, le module "Calendrier". En effet, ce petit module va permettre de créer une nouvelle date butoire, en l'associant à un semestre (S1 ou S2) et d'y ajouter une description (facultative). Une fois ces dates créées, un étudiant appartenant à un groupe pourra (et devra) se rendre sur la page de création de compte rendu et saisir correctement les informations citées plus haut. Une fois créé, les tuteurs recevront une notification de création par mail et pourront donc consulter et valider ce compte rendu. Validation qui s'effectuera grâce à un timestamp et par le nom du tuteur qui l'a validé. Cette validation engendrera la génération en PDF de ce compte rendu et l'effacement du compte rendu temporaire dans la table (afin d'éviter de la surcharger). Bien entendu, une fois validé, ce compte rendu ne pourra plus être modifié et devra être présenté sur le site personnel du groupe de projet! Création de comptes rendus (etudiant) calendrier : Le module de gestion du calendrier permet aux administrateurs de fixer des dates butoirs ( deadline ). Ainsi, grâce au module de gestion des comptes rendu, les étudiants pourront associer un ( ou plusieurs ) comptes rendus à une deadline. Le remplissage de ces dates s'effectuera en début de semestre par les administrateurs. L'affichage du calendrier est accessible via une entrée dans le menu, et les 2 semestres sont distingués. 20

21 Création d'une date butoire (Admin) Affichage d'une date butoire (Admin) parametre : Ce module-crud permet aux administrateurs de gérer les paramètres de la plateforme. L'affichage de ces paramètres est accessible via le menu pour les administrateurs seulement. III Stratégie de répartition du travail Nous avions réaliser une première répartition des tâches que voici : Nils : Gestion droit ( en cours) Réunion Intermédiaire Envoie mail des fonctionnalités Dashboard Diane : Prolog soutenance + Interface Creation de compte rendu (html) Génération de compte rendu PDF + Validation (signature) Vincent : Creation gp temporaire + validation Creation soutenance 21

22 (Stockage archives) Cette répartitions n'as pas été respecté pour plusieurs raisons : Nous n'avions pas découpés en modules chaque application et ainsi évaluer correctement la dose de travail. Nous n'avions pas géré le facteur humain. Nous n'avions pas prévu de marge d'erreur. Nous avons omis les démarches administratives. Nous ne pensions pas que le MCD prendrait autant de temps à être finalisé, tout du moins en partie. Finalement, nous n'avons pu réaliser tout ce que nous avions prévus. Voici, maintenant la réalisation de chacun des membres du groupes : Nils : Intégration du plugin d'authentification Mise en place du système de droits ( Credentials ) Mise en place de la sécurité au sein de la plateforme Création du module de gestion des sujets Création du module de gestion des groupes ( temporaires aussi ) Création des menus personnalisés ( administrateur, tuteur, étudiant ) Gestion des tuteurs, de leur association aux sujets Diane : Gestion administratif Gestion de groupe Rapporteur de réunion Administrateur du site de projet MCD FAQ Retouche graphique Gestion de version de la base de données Chargé de Bug repport et de config server vers le CRI Portabilisation Beta-testeur des fonctionnalités Vincent : Première installation de Symfony et de la plateforme sur Grumly Premier développement du module-crud des groupes Recadrage du groupe pour les conditions de travail Développement du module-crud de réunions (mais qui s'est avéré inutile) Développement des modules-crud de date butoire et de comptes rendus Redéveloppment du module de comptes rendus à la main (suite à un problème majeur avec le module-crud précédemment créé : voir partie "Difficultés rencontrées") Re-design complet du MCD selon notre base de données actuelle (le reverse engineering a été tenté, sans succès) Grâce à cette expérience, nous savons mieux découper les tâches et avons appris qu'il vaut mieux un découpage ambitieux pour être prêt pour la suite du projet. 22

23 Nous avons aussi préféré nous attarder sur chaque fonctionnalité pour un maximum de qualité plutôt que d'en réaliser le plus possible et qu'elles soient défaillantes. IV Difficultés rencontrées Lorsque l'on est amené à travailler en groupe dans un projet, on est toujours confronté à certaines difficultés humaines (communication, présence, ect.) et matériel (outil disponible, matériel de portage, administration des droits ect.). Nous allons détailler dans cette partie l'ensemble des contraintes auxquelles nous avons été confrontés. IV) 1) Humaine IV 1) a) Les Réunions : Nous avons effectués deux réunions de projet par mois, soit deux fois plus que certains autres groupes. Ces réunions fréquentes ont été bénéfiques mais en même temps défavorables au projet. En effet, lors des réunions du début du second semestres, nous avions décidé de modifier le MCD en faisant des reviews régulières envers nos tutrices. Nous sommes restés de janvier à fin mars sur les différentes versions du MCD. A chaque réunion, nous discutions de ce qui n'allait pas, ou redéfinir les besoins exacts des tutrices. Si bien qu'à force de réunion, plus personnes ne savait exactement quel demande de modifications nous avions opéré ni même pourquoi ces modifications, claires au dernier rendez-vous, n'étaient plus pertinentes. Nous avons donc gardé juste une partie validé du MCD pour commencer à travailer en avril. Mais ces réunions régulières ont clairement entretenus notre motivation et nous ont permis d'avancer sans nous disperser. IV 1) b) Vie du groupe : Pour ce projet, nous étions initialement deux groupes constitués de deux membres : Groupe 04 : Nils Charlois et Diane Agnan Groupe 05 : Vincent Sigaud, et Julien Ginoux Julien a arrêté ses études à une semaine juste avant la soutenance du premier semestre. Il s'était occupé de toute l'installation de la plateforme Zend pendant 3 mois qui était hébergé sur son compte. Cet évènement a bouleversé toute l'organisation du projet, des groupes ainsi que des soutenances. Nous avons du inclure en hâte Vincent dans notre groupe, dans notre rapport de fin de semestre ainsi que dans notre soutenance. Le passage à Symfony nous a permis aussi de reprendre toute la main sur le projet, et d'être autonome de l'installation de la plateforme. Nous avons appris à nous adapter et à réagir rapidement au problème. Les conditions de travail au sein du groupe n'ont pas toujours été optimales, nous avons facilement pu sentir une séparation en deux de celui-ci, d'un coté Diane et Nils, et de l'autre Vincent. Diane et Nils se sont formés chacuns de leur côté à Symfony. 23

24 Même si Nils n'a pas hesité à répondre aux demandes de formation de Vincent que ce sois pour virtualiser Linux sous Virtual Box, l'aide à l'installation de Symfony ou même à expliquer la génération des modules-crud (Create, Read, Update, Delete), le groupe à commencé à être divisé. Vincent n'ayant pas pris les devant en montrant son implication, le groupe s'est scindé en deux pendant trois mois, Nils et Diane ayant l'habitude de travailler ensemble. Une séparation pas forcément injustifiée mais tout de même un peu abusive. Les tutrices ont intervenus sur ce problème il y a trois semaines et Vincent s'est remis en question et a reconnu ses fautes. Il est venu s'excuser auprès des autres membres du groupe pour son manque d'implication dans le projet en début de semestre mais a demander à ce que l'on reparte à zéro, en promettant de s'impliquer fortement dans le projet, mais en demandant aussi au reste du groupe de faire un effort au niveau de la communication, et de la cohésion au sein du groupe. Discussion qui a manifestement porté ses fruits et qui a montré son efficacité. Le facteur humain est la clef de la réussite d'un projet, en effet l'optimisation de la communication et de la répartition des tâches permet une bonne conduite de celui-ci. Mais celà ne s'apprend pas en un jour, et c'est avec le temps et l'expérience qu'une bonne conduite de projet s'acquière. IV 2) Matériel IV 2) a) Développement : En voyant la place que prenait les fichiers svn sur la précédente version de la plateforme sous Zend, nous avons préféré travailler chacun en local sur nos machines. Chacun travaillait sur sa partie, et lors du portage sur les serveur du CERI, Diane se chargeait de la fusion du travail de chacun en vérifiant la cohérence entre les parties Symfony et celle de la base de données. Ceci pour éviter que chacun ne détériore le travail de l'autre et pour accroitre la qualité du projet avec une vérification humaine. De plus, les serveurs du CERI étant relativement lent et subissant des plantages de connexions, cette technique ne nous a pas ralenti dans le travail. Module de comptes rendus : A la base, ce module a été créé comme n'importe quel autre module-crud classique : généré à partir de Symfony, puis modifié par la suite. Une des données essentielles à transmettre (et donc à inscrire dans la table) était le numéro de groupe auquel appartient l'étudiant qui crée ce compte rendu. Par le biais de requêtes Doctrine, ce numéro était correctement récupéré, mais nous n'avons pas réussi à l'insérer dans la table lors de la soumission du formulaire. En effet, ce module étant un module-crud généré par Symfony, il a ses propres propriétés, ses propres fonctions. Il est donc très difficile d'ajouter manuellement un champ, ou d'insérer une valeur manuellement dans un champ existant. Nous avons essayé tout ce que nous avons trouvé sur le sujet, mais rien n'y faisait, tout dans le module fonctionnait parfaitement, sauf cette seule et unique donnée, pourtant primordiale, qui ne pouvait pas être insérée dans la table. Nous avons donc décidé de recoder entièrement ce module à la main afin de pouvoir créer nos propres champs, et insérer les valeurs que nous voulons dans la table. Vincent s'est occupé de la partie "ajout" d'un compte rendu et du reste (Affichage de l'index et de la fiche 24

25 détaillée d'un compte rendu, modification, suppression). La partie validation est implémentée par Diane, et comme pour le reste du module, le scénario restera le même. IV 2) b) Portage : Lors du portage de l'application, nous avons été confronté au problème de configuration des serveurs entre projets-gmi et grumly. Voici le détail de ces configurations : Serveur Apache Grumly Apache Projet-gmi Base de données psql (PostgreSQL) PostgreSQL Version Php PHP (built: Mar :14:04) PHP (built: Nov :14:47) memory_limit du fichier php.ini 10 Mb 16 mb La configuration minimal exigé pour Symfony est : Serveur Web quelconque Gestionnaire de base de données : Mysql PostgreSQL SQLite PHP dans sa version ou supérieure memroy limit de php.ini : 12 Mb minimum. 32 Mb pour une application complexe. Comme nous pouvons le remarquer aucun de ces deux serveurs ne continent la configuration minmale. Logiquement, nous aurions du porter l'application sur projets-gmi. Nous avons donc contacté nos tutrices concernant ces manques,qui nous ont par la suite redirigé vers le CRI. Maxime Champelle du CRI nous a contacté en nous demandant exactement ce dont on avait besoin, à savoir soit une aumgentation du memory_limit du php.ini de grumly, sois une nouvelle version de php sur projets-gmi. A chaques mise à jour de logiciel de l'université, la démarche est longue et fastidieuse car les responsable informatique doivent installer des version "certifié" et testé leur stabilité avant de pouvoir entreprendre une installation. Maxime nous as donc octroyé plus de memory_limit sur grumly, dans la journée où il a reçu nos besoins. Ce choix était le plus rapide en tenant compte du délais qu'il nous restait avant la fin du second semestre. 25

26 V Guide d'installation de la Plateforme Afin de pallier au problème d'installation de la Plateforme sur les serveurs de l'iup, nous allons détailler ici tout les manipulations à effectuer pour mettre en place la Plateforme. V 1) Pré-requis Afin de rendre opérationnelle notre plateforme Symfony, il faut des éléments installés sur le serveur. V 1) a) Serveur apache Un server Apache qui comprend : Version de PHP Un gestionnaire de base de données Postgrès SQL Un Version de PHP minimum. Une configuration de PHP 5 de Apache qui alloue minimum 12 MB, qui est amenée à être augmentée selon le développement de la plateforme. Une base de données Postgrès SQL Pour vérifier la version de php sur le serveur, connectez vous sur celui-ci par commande ssh : $ php -v PHP lenny8 with Suhosin-Patch (cli) (built: Mar :14:04) Si la version de PHP est antérieure à la version 5.2.4, aucune fonction du framework Symfony ne fonctionnera. Modification de la mémoire de PHP5 Pour se faire, il faut modifier le fichier /etc/php5/cli/php.in. Repérer la ligne Memory_limit et la modifier comme suis : Memory_limit = 32M ; Maximum amount of memory a script may consume (32MB) ) ex 26

27 Suite à cette configuration, un redemarrage du serveur Apache est souvent nécéssaire. $ sudo /etc/init.d/apache2 restart Une configuration équivalente existe sur le serveur Grumly. V 2) Base de données Deux fichiers sql sont présent dans le répertoire dump : dump.sql, il représente toute la structure des tables de la base de données. data.sql, c'est l'insertion des contenus de la table. Ces deux fichier sont à insérer dans la base de données comme suis : psql (8.4.4) Saisissez «help» pour l'aide. plateforme=>\i dump.sql plateforme=>\i data.sql Pour modifier le fichier d'accès à la base de donnée, il suffit de lancer la commande Symfony : $ php symfony configure:database "pgsql:host=nomduserveur;dbname=nomdelabasededonnées" NomUtilisateur MotDePasse Ou de modifier le fichier config/databases.yml La plateforme des projets est maintenant portabilisé et fonctionnelle. Vous pouvez aussi consulter le site de symfony pour toutes autres questions liés aux portage à l'adresse suivante : 27

28 V 3) Les dossiers Il faut copier le dossier de la plateforme dans un répertoire www. Ensuite, il faut modifier les droits des repertoire /cache et /log en 777 à la racine du projet. Vérifiez bien que vous en avez les droits. /var/www/plateforme$ chmod 777 -R cache/ log/ Une fois cette étape faite, il faut configurer les les PATHS de Symfony afin qu'il puisse trouver les fichiers correctement. En effet, votre plateforme local et à l'université n'auront pas les même chemins de fichiers. C'est un étape très longue à faire à la main, mais heureusement Symfony automatise ce travail à l'aide de la commande : $php symfony cc --type=config V Développer avec Symfony V 1) Le premier module Nous allons partir du principe que la base de données à été modifié et que vous voulez implémenter une nouvelle fonctionnalité. Un ensemble de commandes sont à taper afin de lancer la génération de fichiers par Symfony 1. Afin que Symfony prennent les modifications de la base de données (nouvelle table par exemple), il faut lancer la commande : $php symfony doctrine:build-schema 2. De ce schéma de base de donnes, demandons à Symfony de générer les fichiers de modèles : $php symfony doctrine:build-model 3. Grâce à ces modèles, symfony peut créer les formulaire associés à ces modèles (les formulaires de CRUD : Create Read Update Delete). $php symfony doctrine:build-forms 4. Nous allons maintenant créer un module. Un module est un dossier compris dans le repertoir apps/front/module/ qui sera une fonctionnalité de notre site (exemple sujet, cptrendus,...). $php symfony doctrine:generate-module --with-show --non-verbose-templates front NomDonnéAuModule NomDuModel Cette commande génère un module NomDonnéAuModule dans l'application front pour le modèle NomDuModel. Comme pour la plupart des tâches de Symfony, certains fichiers et certains répertoires ont été créés pour vous sous le répertoire apps/front/modules/nomdonnéaumodule/ 28

29 VI Les commandes Symfony Symfony est un framework qui fonctionne principalement par ligne de commande. Afin d'améliorer la reprise du Projet, nous allons détailler toutes les commandes éxistante de Symfony. Il est à noté que nous utilisons le plugin Doctrine pour la gestion de Symfony. Nous avons créé cette partie pour la prochaine équipe afin qu'elle puisse prendre en main rapidement les commandes Symfony et ainsi développer plus rapidement. VI 1) Génération de la structure La tâche generate:project génére la structure par défaut des répertoires et les fichiers nécessaires pour un projet symfony : apps/ cache/ config/ data/ lib/ log/ plugins/ test/ web/ Nom du répertoire Description Accueille toutes les applications du projet Les fichiers mis en cache par le framework Les fichiers de configuration du projet Les fichiers de données comme les jeux de données initiales Les bibliothèques et les classes du projet Les fichiers log du framework Les plugins installés Les fichiers de tests unitaires et fonctionnels Le répertoire racine Web VI 2) Les namespaces Les commandes de symfony sont régient par un système de namespaces. Chaque namespace contient des fonctionnalités qui lui sont propres. Nous allons détailler ici toutes les commandes disponibles. VI 2) a) Doctrine Le template des commandes Doctrine est $php symfony doctrine Vous leur assignerez à la suite de ce template les fonctions ci-dessous : 29

30 Commande :build :build-db :build-filters :build-forms :build-model :build-schema :build-sql :clean-model-files :create-model-tables :data-dump :data-load Description Génère le squelette basé sur le schéma de la base de données. Crée la base de données du modèle courant (doctrine:create-db) Crée les filtres de formulaire par rapport au modèle courant. Crée les classes formulaires du modèle courant. Crée les classes selon modèle courant de la BDD. Crée le schéma selon la base de données existante. Crée les fichiers SQL du modèle courant. Efface tout les modèles de classes générés qui n'éxiste plus dans votre schéma YAML. Efface et recrée les tables à partir d'un modèle spécifique Efface les données dans la BDD Charge les données dans la BDD à partir d'un YAML :delete-model-files Efface toutes les données générées automatiquement pour un nom de model donné :dql :drop-db :generate-admin :generate-migration Exécute une requête DQL et affiche le résultat. Efface la base de données du modèle courant Génère un module administrateur pour doctrine. Génère les classes de migration :generate-migrations-db Génère les classes de migration à partir d'une connexion à une base de données éxistante. :generate-migrations-diff Génère les classes de migration en effectuant la différence entre les anciens et 30

31 les nouveaux schémas. :generate-migrations-models :generate-module :insert-sql :migrat Génère les classes de migration à partir de modèles existants Génère un module Doctrine Insert du SQL pour le modèle courant Migre la base de données vers une version courante ou spécifiée. VI 2) b) Generate Le template des commandes Doctrine est $php symfony generate Vous leur assignerez à la suite de ce template les fonctions ci-dessous : :app :module :project :task Commande Description Génère une nouvelle application Génère un nouveau module Génère un nouveau projet Génère un nouveau squelette de classe pour une nouvelle tâche VI 2) b) Configure Le template des commandes Doctrine est : $php symfony configure Vous leur assignerez à la suite de ce template les fonctions ci-dessous : :author :database Commande Description Configure le nom de l'auteur Configure le DNS de la base de données 31

32 VII) Conclusion Le choix de redévelopper une application depuis le début ne fut pas chose aisée mais à porté ses fruits. En effet, nous avons beaucoup appris en manipulant le framework Symfony et avons développé notre esprit de synthèse ainsi que nos aptitudes autodidacte. Nous avons du aussi nous conformer aux problèmes matériels des serveurs du CERI, nos droits n'étant pas suffisant pour faire ce que l'on souhaitait et leurs capacités étant limitées. Cette capacité à s'adapter à de nouvelles technologies sera très utile dans le monde du travail où il faut remettre en cause à chaque instant le système d'informations sans hésiter à l'adapter à ces nouvelles technologies. Nous pensons avoir fait le bon choix d'une plateforme stable en privilégiant la qualité, plutôt que la quantité de fonctionnalités présentes. Le management d'un groupe de projet est toujours complexe car il faut s'adapter à chaque humain qui compose le groupe. En effet, les connaissances et les compétences de chacun étant d'un niveau différent, il faut réagir en conséquence pour la bonne conduite du projet. La motivation est un facteur déterminant pour un avancement correcte du projet, il faut sans cesse se remettre en question et réagir de manière constructive aux difficultés que l'on rencontre. Le facteur humain est la clef de la réussite d'un projet. En effet l'optimisation de la communication et de la répartition des tâches permet une bonne conduite de celui-ci. Mais celà ne s'apprend pas en un jour, et c'est avec le temps et l'expérience qu'un bonne conduite de projet s'acquière. VIII) Remerciements Maxime Charpenne pour sa réponse et son intervention rapide aux problèmes. Olivier Millet pour avoir su diriger nos demandes. Arnaud Didry et Romain Deveaud pour leurs connaissances en matière de Symfony et pour la mise en place du tunnel LDAP. Corinne Fredouille et Sophie Nabitz pour l'encadrement. Jacques Vabre pour son café qui nous a fait tenir durant nos dures nuits de codage. La musique comme remonte morale. Pidgin, Skype, GoogleDoc 32