Rapport de projet Site Intranet de l`IUP GSI

Transcription

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
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.
3
15/11/2003
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
4
15/11/2003
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.
5
15/11/2003
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.
6
15/11/2003
-
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).
7
15/11/2003
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
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
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.
9
15/11/2003
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.
10
15/11/2003
-
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).
11
15/11/2003
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
12
15/11/2003
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.
13
15/11/2003
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)
14
15/11/2003
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)
15
15/11/2003
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()
16
15/11/2003
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
17
15/11/2003
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
18
15/11/2003
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.
19
15/11/2003
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.
20
15/11/2003
-
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
21
15/11/2003
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é
22
15/11/2003
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.
23
15/11/2003
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 ».
24
15/11/2003
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.
25
15/11/2003
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é.
26
15/11/2003
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
27
15/11/2003
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 :
28
15/11/2003
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
29
15/11/2003
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.
30
15/11/2003
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.
31
15/11/2003
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
b
les balises de mise en forme « gras » ressembleront à cela :
[b]du texte[/b]
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].
32
15/11/2003
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
33
15/11/2003
-
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, …).
34
15/11/2003
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.
35
15/11/2003

Rapport de projet Site Intranet de l`IUP GSI

Transcription

Documents pareils

Fonctionnalités

concours FFTL du 13 mars 2016

Ouverture du serveur 7days Alpha13

Newsletter

Aktu Spectacle - David Copperfield à Montpellier

Scan Bleach Chapitre 480 VF

UNIVERSITE D`EVRY VAL D`ESSONNE - CFA-EVE

HotSpot Parking takes aim at drunk driving in Fredericton

Patch Battlefield 2

cdcaprog2010 fini1