Rapport de projet Site Intranet de l`IUP GSI
Transcription
Rapport de projet Site Intranet de l`IUP GSI
Laurent LECOCQ Fabrice ODESSER Sébastien ACTIS IUP GSI d’Annecy 3ème année SICE Année 2002/2003 Rapport de projet Site Intranet de l’IUP GSI Tuteur de projet : Mr Hervé VERJUS Responsable projet : Mr Thierry YVEN Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS SOMMAIRE INTRODUCTION : ................................................................................................................ 4 GESTION DU PROJET : ....................................................................................................... 4 OBJECTIF : .................................................................................................................... 5 ANALYSE DU PROCEDE : ................................................................................................ 5 ANALYSE DE L’EXISTANT : ................................................................................................. 6 INTRANET : .................................................................................................................... 6 BASE DE DONNEES : ...................................................................................................... 7 CAHIER DES CHARGES : .................................................................................................... 8 CHOIX DES OUTILS : ...................................................................................................... 8 MODELISATION DE LA HIERARCHIE DU SITE : ................................................................... 8 DESCRIPTION DES FONCTIONS DU SITE :......................................................................... 9 CONCEPTION DETAILLEE POUR LA PARTIE GED : .......................................................... 12 CONCEPTION DETAILLEE POUR LA PARTIE AFFICHAGE DES DOCUMENTS : ...................... 17 CONCEPTION DETAILLEE POUR LA PARTIE NEWS : ......................................................... 18 REALISATION : .................................................................................................................. 19 DESIGN DU SITE : ........................................................................................................ 19 GESTION DE LA GED : ................................................................................................. 19 AFFICHAGE DES DOCUMENTS :..................................................................................... 26 GESTION DU MOTEUR DE NEWS : .................................................................................. 27 UTILISATION DU MOTEUR DE NEWS : ............................................................................. 30 SECURITE ET DEBUGAGE : ............................................................................................. 31 DIFFICULTES RENCONTREES : ...................................................................................... 33 AMELIORATIONS POSSIBLES : ....................................................................................... 34 CONCLUSION : .................................................................................................................. 35 IUP GSI 3ème année 2 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Présentation de l’IUP L’IUP GSI d’Annecy-le-Vieux forme des ingénieurs maîtres en deux ans. Il comporte actuellement trois spécialités en licences et deux en maîtrise. Le flux d’informations qui réside dans le fonctionnement de cet IUP nécessite une organisation assez complexe. Un site Internet et un site Intranet ont donc été mis en place ainsi qu’une base de données regroupant toutes les informations nécessaires. Notre projet consiste à améliorer ce système d’information, il nous a été demandé de faire une refonte du site intranet de l’IUP afin de permettre une meilleure cohésion entre les informations nécessaires et les informations fournies et afin de permettre une meilleure convivialité dans l’utilisation de ce site. IUP GSI 3ème année 3 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Introduction : Le site Intranet est indispensable pour l'IUP, c’est pour cela qu’une première version à été réalisée. Cependant, du fait d’un manque de temps et de personnel, celui-ci manque cruellement de convivialité et de fonctionnalités. Il nous a été demandé de réaliser une étude afin de déterminer les aspects et les fonctions nécessaires à l’Intranet de l'IUP, de les réaliser et de les mettre en place. La conception de ce projet nécessite plusieurs étapes. Tout d’abord nous avons analysé le besoin et l'existant afin de cerner les problèmes à résoudre et de collecter toutes les informations nécessaires à la réalisation du projet. Nous avons également déterminé les informations et fonctionnalités à garder et celles à exclure. Ensuite, il faut proposer des solutions, apporter son avis, faire des propositions personnelles et déterminer la structure et le contenu du futur site. Une fois la situation bien analysée, nous pouvons réaliser le cahier des charges. Gestion du projet : Comme il le sera expliqué plus loin dans ce rapport, notre projet est décomposable en plusieurs parties quasiment indépendantes. Il nous a donc semblé plus judicieux de travailler en mini-projets. Cela consiste à terminer toutes les étapes d’une fonctionnalité avant de passer à la suivante. L’objectif est donc d’arriver à la mise en place et le débugage d’une partie et de s’assurer qu’elle fonctionne correctement avant de partir sur la suivante. Nous avons aussi choisi de répartir les taches entre les utilisateurs, ce qui ne nous a pas empêché de travailler quelques fois en commun lorsqu’il était nécessaire. Nous n’avons donc pas tous traité les mêmes parties. Planning du projet : Nº 1 18 25 Décembre 02 09 16 23 Janvier 30 06 13 20 27 Février 03 10 17 24 Mars 03 10 17 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 IUP GSI 3ème année 4 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Nº 1 Nom de la tâche Etude générale Durée 20 jours Début Ven 22/11/02 Fin Jeu 19/12/02 10 jours Ven 22/11/02 Jeu 05/12/02 2 Ananlyse de l'existant 3 Audit 5 jours Ven 06/12/02 Jeu 12/12/02 4 Conception 5 jours Ven 13/12/02 Jeu 19/12/02 5 Cahier des charges 10 jours Ven 20/12/02 Jeu 16/01/03 6 Développement 35 jours Ven 17/01/03 Jeu 13/03/03 7 Réalisation 30 jours Ven 17/01/03 Jeu 06/03/03 8 Design 20 jours Ven 17/01/03 Jeu 13/02/03 9 Gestion Electronique d 30 jours Ven 17/01/03 Jeu 06/03/03 10 Moteur de news 25 jours Ven 17/01/03 Jeu 20/02/03 5 jours Ven 07/03/03 Jeu 13/03/03 11 Qualification 12 Phase de tests 2 jours Ven 07/03/03 Lun 10/03/03 13 Debugage 3 jours Mar 11/03/03 Jeu 13/03/03 6 jours Ven 14/03/03 Ven 21/03/03 1 jour Ven 14/03/03 Ven 14/03/03 14 Mise en production 15 Mise en place 16 Qualification 2 jours Lun 17/03/03 Mar 18/03/03 17 Formation 2 jours Mer 19/03/03 Jeu 20/03/03 18 Fin projet 1 jour Ven 21/03/03 Ven 21/03/03 Ce planning correspond à un projet avec 4 heures attribuées par semaines et pour 3 personnes. Il ne prend pas en compte les irrégularités des séances projet. Analyse du besoin : Objectif : L’objectif de ce projet est de permettre aux utilisateurs d’avoir un accès personnalisé aux données qui leurs sont nécessaires et cela de façon conviviale. Cependant, le côté utilisateur n’est pas le seul point à réaliser, la mise en place d’un back office est aussi à étudier. En effet, le but premier est de permettre une maintenance du site la plus automatisée possible pour que cette administration nécessite le moins de personnes et de temps possible. Analyse du procédé : Ce projet se décomposera donc en trois points : - Le design, aussi bien la mise en page que le graphisme, - La partie utilisateur, c’est à dire toutes les fonctionnalités qui seront proposées aux utilisateurs - Le back Office, le plus automatisé possible mais aussi très convivial afin de motiver les utilisateurs. IUP GSI 3ème année 5 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Analyse de l’existant : Intranet : En parcourrant l'Intranet, et en établissant deux enquêtes auprès des professeurs et des étudiants, nous avons mis en évidence les points positifs et les points négatifs du site. Design et mise en page : Le design actuel date de l’ouverture de l’IUP. Celui-ci pose peu de problèmes en ce qui concerne les utilisateurs : seules des remarques sur la qualité des images (pixellisation) ont été émises. Les problèmes concernent plus la mise en page du site. Nous avons relevé des problèmes d'affichage relatifs à l'utilisation de frames. De plus, la disposition utilisée est peu intuitive, ce qui pose des difficultés dans la recherche d'informations. Organisation : L’organisation est le point le plus gênant du site actuel. On distingue plusieurs catégories de problèmes : - Les liens morts, qui ne conduisent à rien ; - Les redondances de liens : certaines pages contiennent jusqu’à trois fois le même lien, ou bien des liens différents qui conduisent à la même page ; - Des parties vides ou abandonnées, telles que la partie « Divers » qui redirige sur une page blanche. Le processus actuel de mise en ligne d’un document Le processus de mise en ligne d’un document sur l’INTRANET est effectué par une unique personne (le webmaster de l’INTRANET) et nécessite plusieurs étapes : - Se procurer le document à mettre en ligne auprès de leur créateur (récupération d’un cours auprès d’un professeur par exemple) - Uploader le document sur le serveur de l’IUP - Télécharger la page HTML présente sur le serveur et sur laquelle on désir faire le lien vers le document uploadé - Faire le lien dans la page HTML téléchargée vers le document uploadé - Uploader la page HTML ainsi modifiée sur le serveur. Suite à l’analyse de ces actions, on peut mettre en évidence une nette amélioration du processus de mise en ligne d’un document : - En effet, la première étape est celle qui prend le plus de temps, et peut être supprimée en décentralisant le travail, ou plutôt en le centralisant sur les personnes les plus à même de le réaliser. Pour ce faire, il faut permettre à chaque responsable ou auteur d’un document de mettre en ligne lui même l’information qu'il désire partager. IUP GSI 3ème année 6 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS - De plus, toutes les autres étapes peuvent être automatisées, afin de simplifier considérablement le travail de chacun. Fonctions et informations : Après avoir analysé tout le site, nous avons pu déterminer les fonctions et informations importantes à conserver, et les fonctions et informations inutiles à supprimer. Voici un tableau récapitulatif recensant toutes les fonctionnalités du site : - Utile programmes et supports de cours emplois du temps informations sur ATE calendrier pédagogique répartition des étudiants GP/Algorithmique informations sur les projets règlement des études charte de l’université de Savoie liste des salles documentation (java, PHP, …) références (liens Internet, livres, …) quotas d’espace disque configuration Netscape Messager Guipsi news Archive des anciens cours Contacts Dates partiels - Inutile plaquette IUP dates clefs rapport Antivirus Netschield partie « Divers » du menu Base de données : Il existe une base de données Mysql du système d'information de l'IUP élaborée lors des projets des années précédentes. C'est cette base que nous utiliserons pour réaliser les fonctionnalités à rajouter dans l'Intranet, en rajoutant les tables et champs manquants. De plus, la plupart des tables de cette base ont des problèmes de conception (notamment en ce qui concerne les cardinalités) et doivent être corrigées (en tenant compte des éventuelles applications déjà créées qui utiliseraient ces tables). IUP GSI 3ème année 7 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Cahier des charges : Choix des outils : Afin de réaliser ce projet, nous avons choisi les outils suivants : • MySQL : pour la base de données. En effet, la base de données du système d'information de l'IUP est de type MySQL et cet outil nous a été imposé par Pascal Guérin. De plus des applications utilisent déjà cette base. • PHP : pour la partie dynamique du site et les relations avec la base de données. Ce langage nous a été imposé par Pascal Guérin. • Pour l’interface graphique (réalisé en collaboration avec le maître de stage), les outils seront ceux utilisés à l’IUP, Dreamweaver et The Gimp. • HTML : pour la présentation des pages Web. • Javascript et les feuilles de style : pour une présentation plus élaborée et dynamique des documents. Modélisation de la hiérarchie du site : Partie utilisateur Documents Administratits News Cours Licence IUP GSI 3ème année Menu du RU Projet Maîtrise Poursuites d’études Emploi du temps 2ème année 8 Moteur de recherche Contacts 3ème année 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Back Office Administration des news GED Gestion des cours Gestion des utilisateurs Gestion du menu du RU Gestion des EDT Gestion des documents administratifs Gestion des thèmes Création d’une news Description des fonctions du site : Partie utilisateur : News : Elle sera affichée comme page d’accueil du site. Elle contiendra toutes les news concernant l’IUP, on pourra les classer par date et par importance, les trier par auteur ou par thème, on pourra aussi utiliser un moteur de recherche interne aux news pour rechercher une news précise. Cours : Chaque visiteur pourra accéder aux cours mis en lignes par les professeurs, ils seront classés par unité d’enseignement et par matière, pour chaque matière, on aura son responsable, son identifiant de module (ex : MS21) et le nom du module (ex : anglais). Pour chaque cours, on aura le nom de celui qui l’a mis en ligne, le nom du cours et la date de mise en ligne. Emploi du temps : Dans cette section, on pourra trouver l’emploi du temps de la semaine courante ainsi que l’emploi du temps prévisionnel des 4 semaines suivantes. Il y aura aussi les dates des partiels avec pour chacune d’elle le nom du responsable du module, le nom du module et la date du partiel portant sur ce module. IUP GSI 3ème année 9 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Projet : Cette section n’a pas encore été étudiée, du coup, nous ne sommes pas en mesure de décrire son fonctionnement et sa composition. Il sera nécessaire de consulter le responsable des projets, Mr Yven, afin de discuter de sa conception de l’espace projet. Menu du RU : Le menu du restaurant universitaire sera mis à la disposition des étudiants sur l’Intranet. Documents administratifs : Cette section contiendra tous les documents de type administratif comme par exemple les fiches de stage, le règlement des études ou la charte de l’Université de Savoie. Poursuites d’études : Elle contiendra la liste des poursuites d’étude connues par l’IUP ainsi que la liste des poursuites d’études réalisée par les anciens étudiants. Contact : Toutes les adresses e-mails et numéros de téléphone importants figureront dans cette section, que ce soit les professeurs, les responsables ou l’administration. Moteur de recherche : Cette section n’est pas à notre charge, c’est l’administrateur réseau, Mr Guérin, qui profitera de notre projet pour installer un moteur de recherche interne à l’Intranet, notre tache se limitera juste à la mise en place de ce moteur de recherche. Back office : G.E.D. : Le logiciel de GED a pour finalité de partager des documents sur l’INTRANET. Pour pouvoir faire cela de façon cohérente, il faut gérer un certain nombre de données annexes. De cette façon chacun pourra accéder rapidement aux données dont il a besoin. La L’INTRANET doit donc de gérer les points suivants : - Les webmasters : ils doivent avoir tous les droits sur toutes les données de l’INTRANET. - Les acteurs : ils facilitent le travail des webmasters en gérant une partie du système d’information. - Les modules : car en ce qui concerne les supports de cours, il faut les rattacher à un module. IUP GSI 3ème année 10 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS - Les unités d’enseignement : car les modules sont rattachés aux unités d’enseignement - Les spécialités proposées par la formation GSI : afin de rattacher les documents qui le nécessitent aux personnes appartenant ou intervenant à une spécialité. De plus, certains modules sont propres à une spécialité. - Les niveaux d’étude : afin de partager les documents relatifs aux personnes appartenant ou intervenant à une année donnée. De plus, les modules (donc les unités d’enseignement) dépendent d’une année donnée. - Il faut pouvoir également pouvoir gérer l’emplacement des fichiers à gérer sur l’INTRANET. - Les types d’information : ils sont au même niveau que les modules, mais permettent de gérer tout document non rattaché à un cours, une spécialité ou une année. Par exemple, on peut citer le menu du RU, les documents administratifs… - Comme le but de la GED est de décentraliser la gestion des documents à mettre en ligne, il faut pouvoir gérer les doits des personnes autorisées à agir sur le système. Ceci est valable pour toutes les sortes de documents à mettre en ligne. - Bien sûr, il faut permettre aux personnes autorisées de pouvoir gérer les documents correspondant aux types d’information pour lesquels ils sont autorisés. Ceci en tenant compte des droits et besoins de chacun. Administration des news : C’est ici que les personnes autorisées à poster des news pourront saisir leurs messages. Elles devront choisir une importance pour ce message et devront lui donner un sujet. Il leur sera aussi demandé d’attribuer un thème à chacune de leur news (ex : Modification EDT). Certaines personnes auront des droits supérieurs à d’autres. Elles seront administrateur des news et pourrons, en plus de poster une news, gérer les utilisateurs (ajout et suppression) et gérer les thèmes (ajout et suppression). IUP GSI 3ème année 11 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Conception détaillée pour la partie GED : Cas d’utilisation de la G.E.D. pour les supports de cours : Cours Administration, délégués, administrateur réseau, étudiants consulter les supports cours gérer les supports de cours <<include>> gestion de l'emplacement des fichiers <<include>> Webmasters Enseignants, intervenants administrer les cours <<include>> <<include>> créer unité enseignements gérer les matières gestion des droits sur les répertoires <<include>> <<include>> Spécialités Niveau d'étude IUP GSI 3ème année 12 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Cas d’utilisation de la G.E.D. pour les emplois du temps : Emploi du temps Administrateur réseau, administration, délégués, étudiants, ensegnants, intervenants consulter l'emploi du temps ajouter l'emploi du temps supprimer l'e mploi du temps Webmaster,reponsable emplois du temps Le reponsable des emplois du temps est désigné par le webmaster, il peut choisir de le faire lui même ou de déléguer une autre personne. Cas d’utilisation de la G.E.D. pour les autres documents : Celui-ci est identique à celui des emplois du temps. IUP GSI 3ème année 13 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Diagramme de séquence ajout d’un fichier : Diagramme de séquence pour l'ajout d'un fichier Utilisateur Ecran Base de données Interface administration Arborescence fichier sur le serveur demande_ajout_fichier() afficher_formulaire_ajout_support_cours entrer(IPF,M,EFS) get_nom(EFS) : nom_fichier élaboration_chemin_destination(IPF,M,EFS, nom_fichier) : chemin copier_fichier(EFS, chemin) IPF : intitulé présentation fichier M : module EFS : emplacement fichier source D : dat e mise en ligne get_date_système() : D get_login() : auteur insérer_infos(IPF, chemin, M, D, auteur) afficher_formulaire_ajout_support_cours IUP GSI 3ème année 14 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Diagramme de séquence suppression d’un fichier : Diagramme de séquence pour la supprssion d'un fichier Utilisateur Ecran Interface administration Base de données Arborescence fichier sur le serveur demande_suppression_fichier() afficher_formulaire_suppression_support_cours entrer(EFS) supprimer_fichier(EFS) FichierSupprimeOK? EFS : emplacement fichier serveur [FichierSupprimeOK?] supprimer_enregistrement(E FS) afficher_formulaire_ajout_support_cours IUP GSI 3ème année 15 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Diagramme de séquence authentification : Utilisateur Ecran Int erface administration Base de données Annuaire LDAP demande_de_connexion() afficher_formulaire_connexion entrer(login,pass) verrifier(login) loginOK? [loginOK?] verrifier(login,pass) autent ificationOK? [autentificationOK?] demande_action_a_effectuer() IUP GSI 3ème année 16 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Conception détaillée pour la partie affichage des documents : Cas d’utilisation de l’affichage des documents : affichage documents <<include>> choisir année consulter cours <<include>> <<include>> choisir module choisir année utilisateur afficher EDT <<include>> choisir période afficher documents IUP GSI 3ème année 17 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Conception détaillée pour la partie news : Cas d’utilisation de l’administration des news : Gest ion des news Administ rat eur rés eau, administration, délégués , ensegnants, intervenants Poster une news Créer un thème Gérer les utilisateurs Supprimer un thème Webmasters,administra teurs des news Administrer les news Créer un thème Gérer les utilisateurs Supprimer un thème Les webmasters sont les personne qui ont les droits ultimes (sur tout le site) Cas d’utilisation de l’utilisation des news : Utilisation des news Voir les news Trier par aut eur Trier par date Visiteur Trier les news Trier par sujet Trier par importance Faire une recherche IUP GSI 3ème année 18 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Réalisation : Design du site : Gestion de la GED : Présentation de la base de données : L’architecture de la base de données est aussi importante que l’arborescence des fichiers car elles constituent toutes deux la base du projet. Une base mal construite peut engendrer des contraintes lors de la phase de développement, voir une impossibilité à mener à bien certaines parties du projet. Il est donc important de prendre son temps pour construire correctement les fondations du logiciel. La base de données a été réalisée sous MySQL mais lors de la phase de conception, nous avons tout de même réalisé une copie des tables et champs que nous devons utiliser sous ACCESS pour profiter du schéma des relations entre les entités. Ce dernier nous servira considérablement lors du développement du logiciel car il permet de respecter l’intégrité de la base en exerçant correctement la suppression de champs en cascade dans les différentes tables. De plus, un tel schéma vaut mieux qu’une longue explication sur la structure de la base car il synthétise l’ensemble des tables utilisées, les champs qui les composent, les clés primaires et secondaires, les cardinalités, et les relations inter entités. IUP GSI 3ème année 19 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Figure 6 : Modèle entités / relations de la base de données Légende et explications : Pour les cours, on gère les unités d’enseignement auxquels ils appartiennent. Pour chaque unité d’enseignement, on gère les diplômes et les spécialités (licence, maîtrise…) auxquels ils sont associés. Pour chaque type d’information (modules ou autres), on gère des éléments communs : - Les fichiers à diffuser - Les acteurs autorisés à gérer le type d’information Enfin, on gère l’emplacement racine des fichiers à manipuler, et les acteurs autorisés à administrer ou à partager des informations sur l’INTRANET. Remarques : - Chaque type d’information (cours ou autre) est géré par un ou plusieurs administrateurs, qui gèrent les fichiers correspondants à diffuser. Ce responsable peut décider d’attribuer à d’autres personnes la possibilité de gérer également ces fichiers. Cela peut être le cas par exemple pour permettre aux intervenants de mettre à disposition les cours qu’ils dispensent dans un module donné. Ces droits d’accès sont gérés dans les tables « gerants_modules » (pour la gestion des supports de cours) et « gestion_repertoire » (pour la gestion des fichiers correspondants aux autres types d’information). - Lors de l’étude préliminaire que nous avons menée pour connaître précisément les informations à diffuser sur l’INTRANET, nous avons pu constater qu’il y avait un certain nombre de « types d’information » à gérer : cours, emploi du temps… De plus, le logiciel devant s’adapter aux besoins futurs de l’IUP en matière de partage de fichiers, il doit pouvoir prendre en compte les documents dont l’IUP aura besoin demain sur son site. Par conséquent, il est nécessaire de réserver une table de la base de donnée pour accueillir chaque type d’information, et à fortiori, pour gérer chaque nouvelle information. C’est de cette table (la table « type_information ») que vient la principale évolutivité du logiciel qui est, de pouvoir tenir compte d’autant de types d’information que nécessaire. IUP GSI 3ème année 20 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS - Le fait que certaines données soient propres aux cours (unités d’enseignement, années, spécialités) impose de gérer ces derniers de façon différente par rapport aux autres types d’information. De plus, parmi ces informations spécifiques, certaines sont indispensables à la position des fichiers (supports de cours) sur le serveur. C’est le cas notamment de l’année (licence, maîtrise) dans laquelle est dispensée le cours. Ceci explique que les cours sont gérés dans des tables différentes des autres types d’information. - Le répertoire racine de l’arborescence des fichiers est choisi par l’administrateur du logiciel, et contenu dans la table « gestion_fichiers ». - L’administrateur du logiciel est le premier acteur entré (dans la table « acces »). Il faut donc indexer le champ Login de cette table, afin de classer les acteurs par ordre d’arrivée. Les autres acteurs ne peuvent que gérer les fichiers correspondant aux types d’information pour lesquels ils sont autorisés, ou autoriser d’autres personnes à gérer les fichiers de leur type d’information (pour les responsables seulement). - Seuls les personnes ayant un login dans la base LDAP de l’université de Savoie pourront se servir du back office de gestion des documents à mettre en ligne sur l'INTRANET. Plan de logiciel : La partie administrateur est plus compliquée que la partie utilisateur car elle accède en écriture dans la base de données, et dans l’arborescence des fichiers. Il faut donc permettre toutes les actions nécessaires (ajouts, suppressions et mises à jour), et établir un certain nombre de tests pour garantir l’intégrité du logiciel. De plus, il existe deux sortes d’administrateurs : l’administrateur général du logiciel (1er utilisateur de la base de données : il a tous les droits), et les administrateurs (acteurs) des types d’information (cours M2-18, emploi du temps…). De plus, l’administrateur d’un type d’information donné peut décider de donner la possibilité à d’autres personnes de gérer aussi ce type d’information. Néanmoins, le plan général est très simple, afin de faciliter d’éventuelles mises à jour des scripts (voir figure 7) : Page d’identification du service Index. h Choix de la partie à gérer par l’administrateur Choix_action.php Formulaires de gestion de la partie choisie Operation_choisie.php (ajout, suppression, mise à jour) Exécution de l’action à effectuer Page de filtrage de la personne connectée suivant sont statut et ses droits Pages de consultation des données de l’INTRANET Résultat de la recherche Fichiers dont l’accès dépend du niveau d’administration Parties administrateur Partie utilisateur Figure 7 : plan du logiciel IUP GSI 3ème année 21 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS On peut voir que le logiciel est très simple et rapide d’utilisation. En effet, une fois identifié, il n’y a qu’une page maximum qui sépare un service « utilisateur » de l’information qu’il recherche. De même, il faut deux pages à l’administrateur avant d’effectuer l’action qu’il a choisie (ajout d’un fichier, suppression d’une autorisation d’accès à une information…). Le maximum doit être fait pour simplifier la tâche de tout le monde. Remarques sur les choix qui ont été fait : Certaines décisions qui ont été prises méritent quelques explications : - C’est à l’administrateur d’un type d’information qu’il incombe de déléguer des pouvoirs à des tiers (ajouts / suppressions de fichiers) sur le répertoire qu’il gère. Ces tiers pourront gérer uniquement leurs propres fichiers dans le répertoire correspondant au type d'information pour lequel ils sont autorisés, mais ne pourront en aucun cas gérer aussi les personnes qui le gèrent. Par contre, la ou les personnes désignées comme responsable d'un type d'information supervisent également les fichiers des tiers, et peuvent ajouter d'autres tiers. - C'est l'administrateur principal (webmaster) qui définit les personnes responsables des types d'information, et ce sont ces dernières (ou les webmasters) qui définissent les tiers. - Afin de maintenir l’intégrité du logiciel, et une cohérence entre la base de données et l’architecture des fichiers, certaines opérations ne sont possibles que sous certaines conditions. Par exemple, on ne peut changer l’identifiant d’un module que si aucun fichier ne lui est associé. Ceci venant du fait que ce champ intervient dans le nom des répertoires de l’arborescence des fichiers. Explication des fonctionnements du logiciel INTRANET : Le but de cette partie est de définir la logique avec laquelle la gestion des documents doit être conçue, et de mettre en valeur les points importants quant aux choix qui ont été faits pour le développement. 1 – Ajouts divers Au niveau des ajouts de données, on ne permet pas d’insertion de côte ou double côte dans la base de données : ceux-ci sont remplacés par des espaces. De même, au niveau des données intervenant dans les chemins de répertoires ou fichiers, on ne permet pas les caractères accentués car ils sont interprétés différemment selon les systèmes d’exploitation. Les caractères accentués sont remplacés automatiquement par leur homologue non accentué. Chaque ajout ou association se fait dans une seule table à la fois : - Ajouter une année d’études (licence, maîtrise…) se fait dans la table "Diplomes", (fichier : nouveau_diplome.php). On vérifie simplement que le champ entré n’est pas nul avant de l’insérer dans la base de données. Ceci afin de ne pas entrer d’identifiant nul dans la base de données. - Ajouter une nouvelle unité d’enseignements se fait dans la table "Unite" (fichier : nouvelle_unite.php). On vérifie simplement que les champs entrés ne sont pas nuls avant de les insérer dans la base de données. Ceci afin de ne pas entrer d’identifiant (clé IUP GSI 3ème année 22 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS primaire) nul dans la base de données, et de ne pas perturber l’affichage des données (non clé primaire) lors de la consultation. - Ajouter une nouvelle spécialité (ISI, AISI…) se fait dans la table "specialite" (fichier : nouvelle_specialite.php). On vérifie simplement que le champ entré n’est pas nul avant de l’insérer dans la base de données. Ceci afin de ne pas entrer d’identifiant nul dans la base de données. - Ajouter un nouveau type d’information crée une entrée dans la table « module » ou "type_d_information", suivant que l’on veut créer un nouveau cours ou un autre type d’information (fichier : nouveau_type_d_information.php). En créant un nouveau module, on ajoute également le responsable correspondant comme administrateur par défaut de celui-ci dans la table "Gerants_modules". Tous les champs sont obligatoires. - Autoriser un acteur à gérer un type d’information (ajout / suppression de fichiers à partager) rajoute une entrée dans la table "Gerants_modules" ou "Gestion_repertoire", suivant que l’on désire attribuer la gestion d’un cours ou d’un autre type d’information (fichier : nouvelle_gestion_acteur_repertoire.php). - Associer un fichier à un cours ou à un autre type d’information revient à ajouter une entrée, respectivement dans la table "supports_cours" ou « Fichiers » (fichier : associer_fichier_type_information.php). Tous les champs sont obligatoires. - Ajouter un nouvel acteur du site INTRANET revient à ajouter une entrée dans la table "acces" (fichier : nouvel_acteur.php). L’ajout d’un nouvel acteur dans cette table n’est possible que s’il est inscrit dans l’annuaire LDAP de l’université de Savoie. 2 – Définir la racine de l’arborescence des fichiers Fichier : attribuer_racine_arborescence.php Il ne peut y avoir qu’une seule racine pour l’emplacement des fichiers. De ce fait, une fois une racine définie dans la base de données, on ne peut que la mettre à jour : pas de nouvelle insertion de racine dans la base (table "gestion_fichiers"), ni de suppression possible. D’autre part, on ne peut changer la racine de l’arborescence, uniquement s’il n’y a pas encore de fichier associé à des types d’information. Ceci afin d’éviter l’inaccessibilité des fichiers déjà gérés par le système, ainsi que toute incohérence entre le chemin réel des fichiers, et le chemin inscrit dans la base de données. 3 – Suppression d’un acteur Fichier : supprimer_acteur.php L’administrateur peut supprimer autant d’acteur qu’il souhaite (dans le cas par exemple où il voudrait décharger un acteur de s’occuper de l’INTRANET). La seule restriction vient de la suppression du compte administrateur. Celui-ci ne peut être supprimé que s’il n’existe plus aucun acteur. En effet, comme ces derniers sont indexés par ordre d’arrivée dans la base de donnée, si on enlevait l’administrateur (premier acteur) alors qu’il en reste d’autres, c’est le second acteur qui deviendrait alors administrateur. IUP GSI 3ème année 23 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS De plus, lorsqu’on supprime un acteur de la table « acces », il faut aussi le supprimer des tables Gestion_repertoire » et « Gerants_modules », car la suppression d’un acteur revient à vouloir lui retirer tous ses droits (ou besoins) de gestion des informations. C’est l’application de l’intégrité référentielle, avec suppression des champs en cascade dans la base de donnée. 4 – Suppression d’un fichier (support de cours ou autre) Fichier : supprimer_fichier_type_info.php Les fichiers peuvent être supprimés par n’importe quel administrateur. Néanmoins, on distingue plusieurs points : - L’administrateur principal peut supprimer n’importe quel fichier. - Les gestionnaires responsables des types d’informations peuvent supprimer tous les fichiers correspondant à leur type d’information. - Les gestionnaires « simples » (tiers désignés par les gestionnaires principaux) ne peuvent supprimer que les fichiers qu’ils ont eux même introduit. Supprimer un fichier revient à enlever une entrée dans la table « supports_cours » ou « Fichiers », suivant que l’on décide de supprimer un cours ou un autre fichier. Remarque : On ne laisse jamais de répertoire vide. Par conséquent, si on supprime le dernier fichier ou sous-répertoire d’un répertoire, on supprime aussi ce dernier. Ceci afin de faciliter les recherches de documents par un utilisateur (autorisé par l’administrateur système) directement sur le serveur en cas de panne de l’INTRANET, et de n’archiver que les informations inutiles (un répertoire vide est considéré comme une information inutile). Par ce procédé, on est sûr que chaque répertoire de l’arborescence contient quelque chose 5 – Suppression d’une unité d’enseignement fichier : supprimer_unité.php Supprimer une unité d’enseignement se fait dans la table « Unite ». Cependant, la suppression n’est autorisée que s’il n’y a plus de fichier associé car on considère que l’information est plus importante que le type d’information. On efface également en cascade dans les tables « module » et « ged_gerants_modules ». 6 – Suppression d’une spécialité ou d’une année d’étude fichier : supprimer_specialite.php supprimer_diplome.php Supprimer une spécialité ou une année d’étude se fait respectivement dans les tables « Specialite » et « Diplomes ». Cependant, la suppression n’est autorisée que s’il n’y a plus de fichier associé car on considère que l’information est plus importante que le type d’information. On efface également en cascade dans les tables « Unité », « module » et « ged_gerants_modules ». IUP GSI 3ème année 24 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS 7 – Suppression d’un type d’information (module ou autre) fichier : supprimer_type_d_information.php Supprimer un type d’information, module ou autre, se fait respectivement dans les tables « Type_information » et « module ». Cependant, la suppression n’est autorisée que s’il n’y a plus de fichier associé pour les mêmes rasons que précédemment. Néanmoins, s’il n’y a pas de fichier associé, on supprime également les autorisations de gestion qui lui sont associées dans la table « Gerants_modules » (pour les modules) ou « ged_gestion_repertoire » (pour les autres types d’information). 8 – Suppression d’une autorisation de gestion d’un type d’information fichier : supprimer_gestion_acteur_type_d_information.php Supprimer la gestion d’un répertoire d’un module ou d’un autre type d’information se fait respectivement dans les tables « Gestion_repertoire » et « Gerants_modules » et ne pose pas de problème particulier : il n’y a pas d’effacement en cascade à effectuer. 9 – Mettre à jour d’un type d’information fichier : mise_a_jour_type_d_information.php La mise à jour d’un type d’information fait intervenir les tables « module » ou « Type_information » (suivant que l’on désir mettre à jour les données d’un module ou d’un autre type d’information). On ne peut mettre à jour l’identifiant du type d’information concerné et l’unité de rattachement que s’il n’y a pas de fichier associé, ceci afin de maintenir cohérente la base de données avec l’arborescence des fichiers. Par contre, si on veut changer cet identifiant, on le fait en cascade dans les tables « supports_cours » ou «Fichiers ». 10 – Mettre à jour une unité d’enseignements fichier : mise_a_jour_type_unite.php La mise à jour de l’identifiant (UE), de la spécialité concernée par l’UE, et du niveau d’étude correspondant ne peut se faire que si aucun fichier n’est encore associé car ces champs servent dans l’élaboration du chemin de destination des fichiers (table « Unite »). Les autres champs peuvent être mis à jour n’importe quand. Les mises à jour se font en cascade dans les tables « module », et « ged_gerants_modules ». 11 – Autres mises à jour Les autres mises à jour ne sont pas gérées car elles concernent des données uniques, c’est à dire qui ne sont pas présentes en cascade dans les autres tables). Par conséquent, pour mettre à jour ces données, il suffit de la détruire et de la recréer. Ainsi, si on veut mettre à jour l’intitulé de présentation d’un cours, on supprime ce dernier, et on le réupload avec les bonnes informations. IUP GSI 3ème année 25 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Affichage des documents : Affichage des cours : Les cours sont accessibles à toutes les personnes qui sont connectés directement sur le réseau interne de l’IUP ou depuis l’extérieur après avoir été identifiées par leur login et leur mot de passe. Pour afficher les cours il faut afficher les années proposées par la formation, en fonction de celle-ci rechercher et afficher tous les modules lui correspondant. Ceux-ci sont classés et affichés par unités d’enseignement, pour chacun d’entre eux sera affiché son identifiant et son intitulé. Enfin lorsqu'un module est choisi, on affiche tous les cours qui lui sont associés et ils sont classés par date de mise en ligne. Pour chaque cours il sera affiché son auteur son intitulé sa date de mise en ligne et une description. Pour affiner la présentation de chaque module on affiche en titre de la section l’identifiant, le nom du module ainsi que le nom du responsable de celui-ci avec une possibilité pour l’utilisateur d’envoyer directement un mail à celui-ci. Si l’utilisateur clique sur un cours une nouvelle page s’ouvre et le fichier apparaît dans celleci. L’utilisateur pourra lire le fichier, l’enregistrer ou l’imprimer. En plus de l’affichage classique des cours on propose une section d’accès rapide aux derniers cours téléchargés ceci pour permettre à l’utilisateur de vérifier immédiatement si des cours ont été mis en ligne récemment. Cette section est placée dans la page d’index des modules et dans la page affichant tous les cours d’un module. Elle contiendra les cinq derniers cours mis en ligne qui seront classées par date. Chaque cour aura les mêmes informations que les cours de la section d’affichage. Affichage de l’Emploi du temps : L’affichage de l’emploi du temps est quant à lui beaucoup plus simple que celui des cours. En effet on ne gère pas les différentes années pour faire un tri par année et on ne gère pas la différence entre un emploi du temps de la semaine courante et le prévisionnel sur 4 semaines. On affiche donc tous les emplois du temps répertoriés dans la base de donné et on les classe par date de mise en ligne du plus récent au plus vieux. Pour chacun des emplois du temps on affiche donc l’intitulé et la date de mise en ligne de celui-ci. Il faut aussi savoir que l’on affiche tous les emplois du temps c'est-à-dire que lorsqu’il y en à un qui est périmé, on l’affiche quand même et ce sera donc au webmaster du site d’enlever les emplois du temps qui ne sont plus d’actualité. IUP GSI 3ème année 26 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Affichage des autres documents : On entend par les autres documents tous les types de documents qui auront étés crées au niveau de la GED. On pourra donc y trouver le menu du restaurant universitaire, la plaquette de l’IUP, la charte informatique, et autres documents. Pour afficher tous ces documents on répertorie en premier lieu tous les types de documents exceptés les cours et les emplois du temps. Ensuite pour chaque type de document on liste tous les fichiers et on les affiche par ordre alphabétique. Pour chaque fichier affiché on indique son nom et sa date de mise en ligne. La gestion des noms et de l’espace d’affichage est géré de manière automatique, c’est à dire que si un nom est trop long par rapport à son espace réservé il est tronqué automatiquement et le nom complet est affiché sous forme d’une info bulle lorsque l’utilisateur passe la souris sur le nom. Les champs qui sont protégés de cette manière sont les seuls qui ont une longueur variable à savoir ceux réservé à l’auteur, l’identifiant et l’intitulé du cours et des documents. Après avoir décrit les fonctionnalités des affichages et l’organisation du site on peut se pencher sur l’aspect design et ergonomie du site. Nous avons donc décidé d’adopter une mise en page qui ne tient pas toute la largeur de la page, pour avoir une présentation plus aérée du site. D’autant plus qu'après avoir étudié le contenu que nous allions apposer, il est apparu que nous allions avoir trop d ‘espace à remplir si nous utilisions un site en pleine page. Au niveau de l’organisation interne de la page cela reste assez classique. A savoir un bannière en haut, le menu sur le coté gauche du site, et le contenu sur la partie restante. Le menu quant à lui se compose des liens fixes qui permettront aux utilisateurs de naviguer entre les différentes sections du site. Ces liens sont composés d’un retour à l’accueil du site qui affiche les news. De deux liens pour accéder aux cours, un pour les licences et un pour les maîtrises. D’un lien vers l’emploi du temps, d’un autre vers les documents. Il y a aussi un lien qui renvoie vers l’application des stages déjà en place, d’un autre qui renverra vers l’application des projets qui n’est pas encore en place. Enfin un lien qui affiche une page de contacts. Gestion du moteur de news : Base de données : La base de données utilisée est la même que celle des la GED, elle contient juste en plus les trois tables suivantes Identification : L’identification se fait par l’intermédiaire du module décrit ci-dessus. Afin de distinguer les visiteurs des posteurs de news, on enregistre une variable de session contenant le login de la IUP GSI 3ème année 27 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS personne loguée (si elle fait partie de la base de données LDAP et de celle des personnes ayant le droit de poster des news) ainsi qu’une variable « statu_news » contenant les droits de la personne loguée sur les news (1 s'il a le droit de poster des news, rien s'il n’a pas le droit). A chaque fois que l’on veut vérifier les liens auxquels le visiteur a le droit, on vérifie ces deux variables. Création de news : Pour créer une news, on utilise le formulaire suivant : On doit renseigner un sujet, une importance, un thème et un message. Tous les champs sont obligatoire afin de permettre une meilleur classification des news et afin de facilité les recherches. L’auteur est automatiquement récupéré grâce à la variable de session stockant le login de la personne loguée. Balises de mise en forme : Plusieurs balises de mise en forme sont mises à la disposition des utilisateurs. Elles permettent de rendre une news plus agréable et surtout elles permettent de donner plus d’importance à certaines parties du message. Elles se composent de deux parties, une balise ouvrante, un balise fermante. Voici à quoi ressembles une balise de mise en forme : IUP GSI 3ème année 28 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Il suffit de cliquer sur la balise désirer pour l’insérer dans le message, il faut ensuite mettre entre les deux parties de la balises le texte sur lequel la mise en forme s’appliquera. Le message sera alors enregistré dans la base de donnée à l’état « brute », c’est à dire qu’il faudra interpréter Administration des news : Les administrateurs des news ont les mêmes droits que les posteurs plus les droits sur les utilisateurs et les thèmes. Utilisateurs : Toute personne qui détient les droits d’administrateur des news ou du site entier est autorisé à gérer les utilisateurs. Elle a la possibilité de créer un utilisateur en indiquant son login et ses futurs droits (administrateur ou posteur de news). L’ajout d’un utilisateur nécessite une vérification dans la base de données LDAP. Il est aussi possible de supprimer un utilisateur en le sélectionnant dans la liste proposée. Les administrateurs du site ne font pas parti de cette liste. En effet, par sécurité, nous autorisons la suppression de tous les acteurs du moteur de news (administrateurs des news et posteurs) mais pas celle des administrateurs du site. Cela permet de ne pas se retrouver dans le cas où plus personne ne pourrait gérer les news. Dans le cas où l’on supprime un posteur qui aurait déjà créé une news, cela ne supprimera pas le nom de ce posteur au moment de l’affichage de la nouvelle. Thèmes : Chaque news doit posséder un thème afin d’offrir à l’utilisateur un indicateur lui permettant de savoir en quelques secondes sur quoi porte la news qu’il est en train de lire. Pour cela ont demande de spécifier un thème aux moment de remplir le formulaire de news. Les thèmes ne sont pas libre de choix, on propose à l’auteur de la news une liste de thèmes prédéfinis. Cette IUP GSI 3ème année 29 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS liste est gérée par les administrateurs des news. Ils ont la possibilité d’en ajouter un. Pour cela ils doivent donner un intitulé et choisir une icône qui servira de logo au thème, cette icônes devant être choisie dans une liste. Ils peuvent aussi supprimer un thème en le choisissant parmi les thèmes déjà créés. Cette fois-ci, la suppression d’un thème doit être réfléchie, en effet, toute suppression ne supprimera pas l’intitulé du thème associé à toutes les news déjà créés, mais la liaison entre l’icône qui lui sera associée et l’intitulé n’existera plus, la news n’aura alors plus d’icônes attribuée. En fait, la suppression d’un thème n’a pour rôle que la suppression d’un thème qui vient d’être créé et qui est erroné. Plusieurs solutions alternatives sont possibles mais aucune n’a été choisie et mise en place et ce pour des raisons de temps. Il serait possible d’attribuer une icône par défaut à tous les thèmes supprimés, d’interdire la suppression d’un thème qui serait déjà utilisé par au moins une news ou de garder le thème en mémoire et de le supprimer uniquement de la listes des thème au moment de la création d’une nouvelle. Utilisation du moteur de news : Affichage des news : Par défaut, les news s’affichent par ordre chronologique, de la plus récente à la plus ancienne. Chaque page contient 10 news. Un système de liens permet de naviguer entre les différentes pages. On y trouve un lien « début », un lien « fin » ainsi qu’une suite de liens permettant d’accéder à chaque pages. Bien sure, toutes les pages ne sont pas référencées en même temps, on affiche simplement les liens vers les n page précédents la page actuelle ainsi que ceux vers les n suivantes. Une variable se trouvant au début du fichier affichage_news.php permet de définir ce paramètre n. Les balises de mise en page sont activée lors de l’affichage de ces news, pour cela, on transforme juste les balises que nous avons inventées en leur équivalente en HTML. Tri des news : L’affichage des nouvelles nécessite deux paramètres : • Le type de tri demandé • Le numéro de la page à afficher Ces deux paramètres sont passés en paramètre par l’URL. Ainsi, cette dernière ressemble à l’expression suivante : http://www.gsi/Intranet2/affichage_news.php?var=date2°^°1 Une série de liens permettent de trier les news en fonction de la date, de l’auteur, du sujet, de l’importance ou du thème. Chacun de ces tris peut ce faire de façon croissante ou décroissante. Moteur de recherche : Certaine news sont difficilement retrouvable dans la masse de nouvelles qui est générée, même en utilisant la fonction « tri ». C’est pour cela qu’un module de recherche permet de retrouver toutes les news contenant un texte que l’on aura entré. Ce texte sera alors coloré et uniquement les nouvelles contenant ce texte soit dans leur sujet, soit dans le corps du message, soit dans l’auteur seront affichées. IUP GSI 3ème année 30 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Sécurité et débugage : Accès aux pages par l’URL : Dans le cas où un utilisateur taperait directement dans l’URL l’adresse d’une page à laquelle il n’a pas accès, il sera automatiquement redirigé sur la page d’accueil. Pour ce faire, nous vérifions si les variables de session contenant les droits de chaque utilisateurs autorisent l’accès à la page demandée. Nous vérifions aussi si ces variables sont bien enregistrées en tant que variables de session. Cette sécurité empêche toute personne connaissant le nom de ces variables de leur donner une valeur en passant par l’URL. Par exemple, si un utilisateur entre l’URL suivante « http://…/supprimer_news.php ?mes_droits=total » et que nous ne vérifions pas que « mes_droits » est une variable de session, alors le visiteur pourra accéder à la page supprimer_news.php et provoquer un disfonctionnement (cette exemple est bien sur fictif). Accès aux dossiers : Lorsqu’on utilise des sous dossiers dans un site, si l’utilisateur entre le chemin qui mène à ce dossier dans l’URL, il a la possibilité de voir le contenu de ce dossier. Cela n’a que peu de conséquences mais il n’est pas logique que les utilisateurs y aient accès, même si ce n’est qu’en visualisation. Une solution consiste à placer un fichier HTML se nommant index.html dans chaque répertoire et d’y inscrire soit un code qui redirigera sur la page d’accueil, soit du texte qui expliquera que l’accès est interdit. Champs obligatoires : Certaines informations étant indispensable, certain champs servant à remplir les formulaires sont obligatoires. Une protection a donc été mise en place afin d’obliger les utilisateurs à remplir certains champs. Pour obliger le renseignement d’un champ de texte ou d’une liste de choix, on utilise la fonction javascript suivante : if (document.nom_du_formulaire.nom_du_champ.value.length == 0) { alert("Veuillez indiquer le ???"); return false; } Désactivation des balises : Au moment de l’affichage des différentes informations contenues dans la base de données, il faut désactiver les balises HTLM ajoutées par les utilisateurs frauduleux qui pourraient perturber l’affichage. Par exemple, si lors de la création d’une news le code suivant a été ajouté : <script language="javascript"> alert("Ceci est un message d’alerte") ; </script> Alors une boite de dialogue avec le message « ceci est un message d’alerte » s’ouvrira à chaque fois que la news sera affichée. IUP GSI 3ème année 31 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Pour désactiver ces balises, on utilise la fonction « htmlentities() » Balises de mise en page et moteur de recherche (news): Lors d’une recherche, l’expression demandée est recherchée dans la base de données. Le problème est que les champs de la base de données contiennent le texte qui sera affiché mais aussi les balises de mise en forme à l’état brute (non interprétées). La recherche va donc s’appliquer au texte mais aussi à ces balises. La forme de ces balises sera alors modifiée et l’affichage sera erroné. Prenons comme exemple la recherche de la lettre « b », étant donné que la balise de mise en forme « gras » se présente comme suit : [b]du texte[/b] et que la recherche de la lettre « b » transformera les éléments trouvés en l’expression suivante <font color='#FF7700'><b>b</b></font> les balises de mise en forme « gras » ressembleront à cela : [<font color='#FF7700'><b>b</b></font>]du texte[/<font color='#FF7700'><b>b</b></font>] Pour palier à cette modification non désirée, on utilise un système de balises temporaires qui limite au maximum les risques de manipulation involontaires. Le principe consiste à remplacer toutes les balises de mise en forme par des balises dont le contenu a peut de chance de faire l’objet d’une recherche et ce juste avant d’effectuer la colorations de texte recherché. Nous avons choisi d’utiliser un série de « 0 » dont le nombre est relatif à la balise. Par exemple, la balise « gras » deviendra donc [0]du texte[/0] et la balise « jaune » [0000000]du texte[/0000000]. Une fois la colorisation effectuée, on retransforme les balises de mise en page afin qu’elles retrouvent leur forme originel. Il aurait été possible de travailler directement sur des balises sans signification mais il aurait alors été impossible à l’utilisateur de connaître la signification d’une balise. Par exemple, la balise [bleu] est beaucoup plus parlante que la balise [0000]. IUP GSI 3ème année 32 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Difficultés rencontrées : Difficultés rencontrées pour le moteur de news : Les difficultés rencontrées portent principalement sur : - La gestion des balises de mise en forme avec le moteur de recherche : Les balises de mise en forme sont enregistré dans le message, lorsque nous exécutons une recherche sur ce message, celle-ci s’exécute aussi sur les balise, ce qui provoque des disfonctionnements lorsque l’expression recherchée est contenue dans la syntaxe de la balise. La solution est expliquée ci-dessus. - La gestion des balises de mise en forme : Problèmes d’imbrication des balises et d’interprétation Difficultés rencontrées dans la GED : Les difficultés rencontrées portent principalement sur : - La sécurisation des accès selon 3 types de droits (« webmaster », « admin » et « partage »). Voir mode d’emploi pour plus de détails. - La sécurisation des pages par implantation des alertes Javascript sur les pages de destination plutôt que sur les pages où sont situés les formulaires. Ceci évite qu’une personne malhonnête puisse entrer des données non conformes dans la base de donnée en désactivant l’utilisation de Javascript dans son navigateur INTERNET. - Mise à jour des formulaires à la volée : pour éviter d’avoir trop de widgets encombrés par des champs qui n’intéressent pas l’acteur, et ainsi faciliter l’utilisation du logiciel. En ne remplissant les widgets qu’avec les données utiles pour l’acteur, cela a considérablement compliqué les requêtes sur la base de données (enchaînement des jointures). Difficultés générales rencontrées : - - Les projets ayant commencé avec un mois de retard, nous avons été contraint de prendre sur notre temps personnel pour rendre un produit correct. De plus, vu l’ampleur du projet, il nous a fallut environ 250h par personnes pour rendre un produit correct à la fin, au lieu des 90h initialement prévues. Lors de la mise en commun des parties de notre projet, nous avons rencontré quelques mauvaises surprises. Par exemple, la fenêtre pour se loguer ne filtrait plus correctement les logins. Lors de la migration du site depuis le serveur de projet vers le serveur définitif, nous avons rencontré un nombre important de problèmes dus à une différence de configuration entre les deux serveurs, que ce soit en ce qui concerne la version du serveur HTTP APACHE, ou de la version du serveur de base de données MySQL. Il a donc fallut adapter notre code pour la plupart des problèmes, et faire changer la configuration du serveur pour les autres problèmes, afin de rendre notre site utilisable. Lors de la mise en ligne du site, nous avons convié les futurs utilisateurs à tester ce dernier. De ce fait, tous les bugs nous ont été recensés en même temps, nous obligeant à les prendre en compte sur le champ. Ce phénomène nous a permis d’obtenir IUP GSI 3ème année 33 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS - rapidement un site fiable, mais nous a imposé une forte charge de travail en peu de temps. Nous avons utilisé un certain nombre de tables de la base de données MySQL du SI de l’IUP, afin de nous intégrer avec lui, et de ne pas créer de redondance dans les données gérées. Cependant, ce travail n’a pas été facile à cause d’une mauvaise conception de cette base de données. De plus, nous avons appris au moment de mettre notre projet en production que la base de données allait être migrée vers PostgreSQL… Améliorations possibles : - Par manque de temps, nous avions eu certaines idées que nous avons pu mettre en œuvre. Par exemple un formulaire d’envoi de mail à l’administrateur réseau pour recenser les problèmes, le plan interactif de l’IUP… La gestion des emplois du temps ne tient compte d’aucune spécificité (années d’étude, spécialités…). En effet, à terme, cette gestion doit se faire par un logiciel spécial dont il faudra intégrer les interfaces dans l’INTRANET. Optimiser la présentation du site pour tous les navigateurs web. Intégration, ou amélioration de l’intégration, des modules réalisés dans les autres projets étudiants (gestion des stages, gestion des projets…). Perfectionnement de certaines fonction (ex : possibilité d’importer de nouvelles icônes pour les thèmes, menu dynamique, …). IUP GSI 3ème année 34 15/11/2003 Laurent LECOCQ, Fabrice ODESSER, Sébastien ACTIS Conclusion : Le principal intérêt de ce projet a été de pouvoir traiter toutes ses phases, de la conception à la mise en place et la phase de tests/débugage/sécurité. Cela nous a permis de voir que la phase post-réalisation a une part très importante dans un projet. Nous avions imaginé qu’une fois la mise en place effectuée, le projet était quasiment terminé mais cela n’a pas du tout été le cas. Malgré les nombreuses simulations effectuées sur la version de développement, nous n’avions pas imaginé tous les cas possibles. C’est la phase de bêta test qui nous a permit de faire une simulation grandeur nature de notre application grâce à la participation de la plupart des futurs utilisateurs. Ceux-ci, en exécutant tous les tests qui leurs sont venus à l’esprit, nous ont permit de repérer les disfonctionnements auxquels nous n’avions pas songé. Cette application sera mise en production l’année prochaine car, étant donné la quantité d’informations présentes sur l’ancien Intranet, la migration vers le nouvel Intranet aurait nécessité trop de travail pour être effectuée cette année. Ce projet nous a bien sure permit de compléter nos compétences dans le domaines des technologie du Web, tant pour le design et la programmation que pour la gestion d’un projet Intranet dans son ensemble. La gestion par projet à d’ailleurs été la facette la plus importante du projet. Le travail d’équipe, la gestion par mini-projets, la répartition des tâches et le gestion du planning ont été les points clef de ce projet. IUP GSI 3ème année 35 15/11/2003