rapport de projet sires 2010/2011 : intranet de gestion de...

Université du HavreUFR Sciences et Techniques

Rapport de Projet SIRES 2010/2011 :Intranet de Gestion de Documents

<[email protected]>

Le Havre, 23 janvier 2011

Intranet de Gestion de Documents 23 janvier 2011

Table des matières

Introduction 4

1 La dé�nition du projet 5

1.1 Presentation du sujet . . . . . . . . . . . . . . . . . . . . . . . 5

2 La conception 7

2.1 Les technologies utilisées . . . . . . . . . . . . . . . . . . . . . 72.1.1 Google Web Toolkit . . . . . . . . . . . . . . . . . . . 72.1.2 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Diagramme UML . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Architecture réseau . . . . . . . . . . . . . . . . . . . . . . . . 14

3 La réalisation 16

3.1 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Les modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Module de connexion . . . . . . . . . . . . . . . . . . . 173.2.2 La base de données . . . . . . . . . . . . . . . . . . . . 183.2.3 Module de gestion de pro�l . . . . . . . . . . . . . . . 183.2.4 Le module de création de modèles . . . . . . . . . . . . 203.2.5 Bac à sable . . . . . . . . . . . . . . . . . . . . . . . . 223.2.6 L'arbre des documents et le visionneur . . . . . . . . . 243.2.7 Un module de partage de document . . . . . . . . . . . 253.2.8 Calendrier . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.9 Le module d'administration . . . . . . . . . . . . . . . 27

3.3 Le déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Conclusion 30

Annexes gestion de projet 31

2/45


Table des �gures

1 Représentation d'une architecture RPC avec GWT . . . . . . 82 Un �chier html et un �chier xml par navigateur . . . . . . . . 93 Exemple de représentation d'arbre . . . . . . . . . . . . . . . . 94 Le diagramme de classes épuré . . . . . . . . . . . . . . . . . . 115 Diagramme de base de données complet . . . . . . . . . . . . 136 Architecture simpli�ée du réseau . . . . . . . . . . . . . . . . 147 Fonctionnement du SVN . . . . . . . . . . . . . . . . . . . . . 168 Interface du module de connexion . . . . . . . . . . . . . . . . 179 Schema Client/Serveur/Base de données . . . . . . . . . . . . 1810 Ihm du module de gestion de pro�l . . . . . . . . . . . . . . . 1911 Liste des modèles . . . . . . . . . . . . . . . . . . . . . . . . . 2012 Création/édition des modèles . . . . . . . . . . . . . . . . . . 2113 Sauvegarde et exportation . . . . . . . . . . . . . . . . . . . . 2114 Bac à sable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315 Boite de dialogue du Bac à sable . . . . . . . . . . . . . . . . 2316 Module de visualisation . . . . . . . . . . . . . . . . . . . . . . 2517 Un module de partage de document . . . . . . . . . . . . . . . 2618 Calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719 Une administration des utilisateurs . . . . . . . . . . . . . . . 2720 Administration des �lières . . . . . . . . . . . . . . . . . . . . 2821 Administration des matières . . . . . . . . . . . . . . . . . . . 29

3/45


Introduction

Dans le cadre du Master 2 MatIS (Mathématiques et Informatique desSystèmes complexes et distribués) de l'université du Havre, il a été demandéaux étudiants de l'option SIRES (Systèmes Informatiques, Réseaux Et Sécu-rité) de réaliser un projet en groupe tout en faisant comme s'il s'agissait d'unprojet au sein d'une entreprise. Chaque groupe s'est vu ensuite remettre uneliste de sujets proposés par plusieurs enseignants de la �lière informatiquede l'université. Une sélection fut ensuite e�ectuée a�n d'attribuer un sujet àchaque groupe suivant un ordre de préférence.

À l'intérieur de chaque groupe, constitué de quatre à cinq étudiants, dif-férents rôles sont attribués a�n de simuler au mieux la conception de projetdans une SSII. Parmi ces rôles, ont été attribués les rôles de chef de projet,de responsable communication, de responsable qualité de responsable gestiondes risques et de responsable production et déploiement.

À travers ce document, le sujet du projet en question vous sera présentéen détails avec une explication, une description des utilisateurs �naux ainsiqu'une présentation succinte des modules implémentés. Dans une secondepartie, la conception sera abordée en évoquant les technologies utilisées etles di�érentes structures au sein de l'intranet, de la base de données et del'architecture réseau. En�n, la réalisation du produit occupera une troisièmepartie comprenant l'Interface Homme-Machine, une description aboutie desmodules ainsi que les outils utilisés.

À la suite de ce document suivra une partie annexe qui traitera plusparticulièrement de la gestion de projet.

4/45


1 La dé�nition du projet

Le projet attribué aux membres de groupe le 18 novembre 2010 est intitulé"Intranet d'administrations des enseignements".

1.1 Presentation du sujet

Le sujet donné par le client est comme suit :Réalisation d'un intranet (langage non déterminé) permettant de gérer toutela partie administrative des enseignements à l'université. Les étudiants de-vront établir un cahier des charges en prospectant auprès des responsablesadministratifs de notre UFR puis établir les besoins auprès de di�érents co-ordinateurs de disciplines et responsables de �lières. Un site intranet seraensuite proposé pour automatiser un certain nombre de tâches.Les technologies utilisées pour ce site devront être également ré�échies, pours'adapter aux di�érents utilisateurs. Le site devra évidemment proposer unepartie administrateur et une partie utilisateur distinctes. Ajax et sqlite sontfortement conseillés a�n de rendre cet outil ergonomique, rapide et simpled'utilisation.

Explication des termes du sujets :� Un intranet est un réseau informatique privé utilisé en interne dans uneentité. Il permet entre autres un accès rapide et un partage contrôlé de�chiers. On dé�nit donc par site intranet, un site visible sur un réseaulocal au sein de l'entité en question.

� Un cahier des charges est un document dans lequel la maîtrise d'÷uvre(les personnes chargées de la réalisation) doit lister les attentes duclient. Ce document sert de base tout au long du projet a�n de ré-pondre au mieux aux besoins évoqués.

� Ajax est un ensemble de technologies qui permet d'ajouter du dyna-misme lors de la navigation entre les pages web d'un site.

� SQLite est un langage informatique utilisé dans un système de gestionde base de données.

� L'ergonomie d'un site est caractérisée par la compréhension instinctivepar l'utilisateur des fonctionnalités. Cette idée, aussi connue sous lenom de KISS (Keep It Simple and Stupid), qui stipule par exemplequ'un bouton avec une croix permet de fermer une fenêtre.

5/45


Les utilisations du projet

Les utilisateurs �naux peuvent être divisés en trois catégories : les en-seignants, les responsables de �lière et les coordinateurs d'un ensemble de�lières. Suite à une réunion avec une demi-douzaine d'entre eux, des besoinsont pu être cernés. Ces besoins ont permis de dé�nir une liste de modulespouvant constituer un cahier des charges.

Soit cette liste :� un module pour se connecter et se déconnecter,� un calendrier a�chant des évènements datés,� un bac à sable pour gérer l'attribution des matières d'une �lière,� un module d'aide à la génération de documents,� un archivage de documents,� un module d'administration pour la gestion du site,� un module de partage de documents.

Chacun des enseignants peut produire de nouveaux documents, les consul-ter et les partager avec ses collègues, il peut aussi accéder et modi�er sesdonnées personnels dans le module pro�l et consulter les évènements du ca-lendrier.En plus de ces actions, un responsable de �lière peut e�ectuer des simulationspour la répartition matières/enseignants à l'aide du bac à sable.Le coordinateur a, quant à lui, la possibilité de faire ces simulations sur toutesles �lières qu'il gère ainsi que de valider ces simulations impliquant une miseà jour de la base de donnée.Le dernier utilisateur est l'administrateur de l'intranet. Cet utilisateur a ac-cès au module d'administration qui permet de gérer les utilisateurs, les �lièresainsi que les matières.

6/45


2 La conception

2.1 Les technologies utilisées

Dans les contraintes imposées par le client, le choix des technologies est unpoint assez important. Les questions techniques se sont donc posées quelquestemps avant la conception, car à la fois la représentation des diagrammesUML (Uni�ed Modeling Language) et la mise au point de l'architecture ré-seau seront beaucoup impactés par le choix de la technologie principale.

En quelques mots, la contrainte sur les outils utilisés est qu'elle impliqueune période de veille technologique au groupe de travail. Nous devions ap-prendre du projet, non seulement au niveau de la gestion d'un groupe deprojet, mais aussi de l'environnement technologique.

Après avoir exposé les avantages et les inconvénients de chaque langagepouvant se prêter à ce type de projet, nous avons décidé de se lancer dansune période de veille sur la technologie Google Web Toolkit. Cette semained'apprentissage a eu pour but à la fois d'apprendre comment utiliser cettebibliothèque, mais aussi de conclure sur ses avantages et ses inconvénients.Comme vous l'aurez deviné, c'est GWT qui a été retenu, pour son côté no-vateur, ce qui répond parfaitement aux attentes du client. Le second choix,qui a été écarté, fût PHP, un autre langage de programmation web, mais quetout le monde connaissait déjà dans le groupe. Et même si il aurait été plussimple de développer l'intranet avec PHP sous certains aspects, le résultataurait très certainement été moins dynamique et moins fonctionnel.

De cette semaine de veille est ressortie une maquette, qui a fait o�ceaussi de démonstration technologique. Grâce à cela, nous avons selectionnédes fonctionnalités incluses dans GWT. C'est ainsi que la conception s'estfaite en concordance avec ce que ce framework pouvait o�rir, pour que laréalisation soit plus simple par la suite.

Nous allons maintenant présenter les technologies retenues, ainsi que lesraisons de ces choix.

2.1.1 Google Web Toolkit

GWT est un logiciel libre sous licence Apache 2.0 développé par Google,dont la première version est sortie en mai 2006. Nous utilisons pour ce projetla version 2.1 sortie en octobre 2010. Le concept part d'une idée innovantepour l'époque : le développement se fait en Java et le compilateur de GWTgénère le code Javascript correspondant. L'équipe de programmation peut

7/45


ainsi utiliser un environnement Java pour coder, déboguer mais aussi dé-ployer les parties client et serveur de l'application.

D'un côté, la partie client sera exclusivement composée de codes html,Javascript et CSS, tous compatibles avec les navigateurs courants (MicrosoftInternet Explorer, Mozilla Firefox, Google Chrome, Opera et Apple Safari).

De l'autre, des servlets Java côté serveur permettent une communicationclient/serveur asynchrone, grâce au protocole réseau RPC (Remote Proce-dure Call).

Figure 1 � Représentation d'une architecture RPC avec GWT

Tout cela est nativement géré par GWT et permet un développementuniforme du client et du serveur.

Un des gros avantages de GWT est qu'il gère nativement les di�érencesentre les navigateurs. Que ce soit pour le code Javascript ou les scripts CSS,chaque navigateur possède des variantes quant à l'interprétation du code.Ainsi, pour le développeur, il est désormais inutile de se soucier de la com-patibilité du navigateur, et l'implémentation devient transparente.

Chaque version générée est accessible par le navigateur visé, car le com-pilateur de GWT créé un �chier html et un �chier xml uniques avec des

8/45


références vers un �chier css unique lui aussi :

Figure 2 � Un �chier html et un �chier xml par navigateur

De plus, nous avons à disposition un nombre très important d'objets pournous faciliter le développement. Par exemple, l'arbre de documents, que nousdétaillerons dans la prochaine partie, est représenté par un simple objet detype Tree.

Figure 3 � Exemple de représentation d'arbre

Pensons aux possibilités qu'o�re GWT et aux facilités que ce frameworko�re, et comparons cet exemple avec la di�culté de produire le même résul-

9/45


tat en PHP, même avec toutes les bibliothèques existantes.

Pour conclure, GWT o�re beaucoup d'avantages, tels que l'architectureréseau et les objets pré-existants, mais aussi quelques défauts, certainementdus à un certain manque de maturité. Ainsi, le déploiement est relativementlong et devient très pénible lors de longues phases de tests. Mais ceci vientégalement du fait que GWT e�ectue un travail considérable pour la compa-tibilité pour un maximum de navigateurs.

2.1.2 PostgreSQL

Pour le stockage des données, nous avons décidé d'utiliser PostgreSQL,un système de gestion de base de données libre selon les termes de licenseBSD. PostgrSQL est quasi-conforme aux normes SQL, est multi-plateformeset est pratiquement aussi stable qu'Oracle. La possibilité de faire des accèsconcurrents à la base, ce qui répond à la multitude d'accès qu'implique un sitedynamique et utilisant les technologies Ajax à foison. En e�et, postgreSQLest reconnu de tous pour sa capacité de stockage et d'insertion massive dedonnées.

2.2 Diagramme UML

La partie conception implique la mise en forme d'un diagramme de classe,respectant ici les normes UML. Nous avons fait en sorte que chaque objetpossède une seule instance pour chaque client. La mise en place de modules,tous instanciés dans un objet permettant d'a�cher des onglets, permettent defacilement répartir les tâches pour le groupe, mais aussi d'assurer de futuresévolutions du projet. Ajouter un module ne demande que deux lignes de code,et est instantanément ajouté en tant qu'onglet. La conception s'est donc faîteavec un oeil vers l'avenir, car il était demandé une évolution possible duprogramme, dans le cadre d'un éventuel futur projet par exemple.

10/45


Figure 4 � Le diagramme de classes épuré

2.3 Base de données

Le diagramme de base de données a été créé très tôt dans la conception,et nous a permis de déterminer toutes les données que devra traiter le logiciel.Cependant, et pour des raisons évidentes de modi�cations et d'ajustementsdu programme, les tables dans la base de données ont également été modi�ées.

La création des tables se fait grâce à un script SQL que l'on exécute lorsde la mise en place du serveur. Voici un exemple de création de table :

CREATE TABLE teacher (

teacher_login varchar(32) PRIMARY KEY,

teacher_name varchar(64),

teacher_firstname varchar(64),

teacher_password varchar(32),

teacher_grainofsalt varchar(3),

teacher_email varchar(32),

teacher_tel varchar(12),

teacher_quota numeric,

teacher_status integer

);

Il est question ici de tables standards telles que teacher qui représente lesdonnées utilisateur (identi�ant, mot de passe, nom, prénom etc.), mais aussi

11/45


quelques tables de liaison, qui permettent la mise en relations de tuples detables di�érentes.

De plus, aucun �chier n'est stocké dans cette base, mais uniquement deschemins vers des �chiers stockés sur le serveur.

12/45


Voici un schéma de la base de données �nale :

Figure 5 � Diagramme de base de données complet

13/45


2.4 Architecture réseau

L'architecture réseau empreinte le modèle RPC (Remote Procedure Call),qui consiste à rendre possible l'appel à des procédures sur une machine dis-tante grâce à un serveur d'application. Le serveur est matériellement dans lebureau du client et est branché sur le réseau intranet de la faculté. La partielogiciel est assurée par un serveur Tomcat, qui permet d'exécuter les servletsdéveloppés pour le projet.

Figure 6 � Architecture simpli�ée du réseau

L'accès à ces ressources se fait par communication réseau sécurisée parle protocole SSL (Secure Sockets Layer). Celui fournit la sécurité nécessaireà l'envoi de données critiques telles que des mots de passe. SSL fournit lessécurités suivantes :

� l'authenti�cation du serveur.� la con�dentialité des données échangées.� l'intégrité des données échangées.� de manière optionnelle, l'authenti�cation ou l'authenti�cation forte duclient avec l'utilisation d'un certi�cat numérique.

14/45


� la spontanéité, c'est à dire qu'un client peut se connecter de façontransparente à un serveur auquel il se connecte pour la première fois.

� la transparence, qui a contribué certainement à sa popularité. Du faitque les protocoles de la couche d'application n'aient pas à être modi�éspour utiliser une connexion sécurisée par SSL. Par exemple, le protocolehttp est identique, que l'on se connecte à un schème http ou https.

Cette couche protocolaire supplémentaire permet de sécuriser les transactionsclient/serveur et même si les documents ne sont pas jugées critiques parle client, les mots de passe utilisés par les utilisateurs peuvent être sourced'intrusion sur d'autres réseau si ils sont utilisés à plusieurs reprises.

15/45


3 La réalisation

3.1 Les outils

Comme nous avons pu le voir précédemment, pour réaliser ce projet nousavons utilisé le langage JAVA (GWT). Ainsi, nous avons utilisé un IDE com-mun à tous les membres du projet a�n de pouvoir non plus partager desimples sources, mais directement un projet.

Eclipse : est un IDE (Environnement de développement intégré) com-plet et très e�cace pour la programmation JAVA. De plus, il dispose d'unmodule très bien intégré pour l'implémentation de GWT. Cela nous a aussipermis de partager l'ensemble des sources, mais aussi l'ensemble des �chiersde con�guration par SVN.

SVN : (SubVersioN) est un système de gestion de versions. Ce systèmepermet donc le travail collaboratif. Dans notre cas, nous avons utilisé le SVNde Google Code. Cet outil proposé par Google est simple d'installation etd'utilisation. Pour ce qui est des clients de subversion, nous avons utiliséTurtoise (pour Windows) et RapidSVN (pour Linux).

Figure 7 � Fonctionnement du SVN

Itext : est une librairie JAVA gratuite et très complète permettant degénérer des PDF (sans aucun message ou publicité). Nous l'avons utilisé a�nde générer des PDF à partir d'un code HTML. L'intérêt de cette librairie estaussi le suivi par son créateur, mais aussi l'entre-aide de la communauté.

16/45


3.2 Les modules

3.2.1 Module de connexion

Comme tous systèmes de gestion de �chiers personnels, notre projet pos-sède un module de connexion garantissant la con�dentialité des documents.

Figure 8 � Interface du module de connexion

Pour réaliser ce module, nous utilisons une interface simple qui permet àl'utilisateur de renseigner son "Identi�ant" ainsi que son "Mot de passe". Unefois la demande de connexion e�ectuée, le client fait une demande de sessionau servlet en charge de la session. Ce dernier véri�e l'existence de l'utilisateurdans la base de données. Le serveur e�ectue donc le cryptage du mot de passesaisie a�n de le comparer a�n de le comparer avec celui contenu dans la basede données. Le cryptage e�ectué est un cryptage MD5 en utilisant en plus latechnique du Grain de sel. Cette technique consiste à concaténer une chainede caractère au mot de passe a�n de complexi�er ce dernier. Cette chaineunique aléatoire, est générée lors de la création de l'utilisateur elle sera aussistockée dans la base de données. Une fois les véri�cations e�ectuées, le serveurcrée une session et retourne la chaine de caractère servant d'identi�ant de lasession au client. Ce numéro est alors stocké par le client dans un Cookieet ne sera détruit que lors de la déconnexion ou la fermeture du navigateurinternet.Si la connexion est e�ectuée, l'interface complète est alors a�chée selon lesdroits de l'utilisateur.

� L'administrateur possède tous les droits et à donc accès à tous lesmodules.

� Un chef de �lière lui a accès a tous les modules sauf celui de l'adminis-tration

� Un Professeur quant à lui n'a ni accès à "Administration" ni au module"Bac à Sable".

17/45


3.2.2 La base de données

L'ensemble des accès à la base de données est e�ectué par le biais d'unservlet qui sert de relais entre le client et la base de données.

Figure 9 � Schema Client/Serveur/Base de données

Pour chaque action à e�ectuer sur la base de données, il existe une fonc-tion respective.

� select - retourne le résultat de la requête sous forme d'un HashMapayant pour clef le nom de la colonne de la table et pour valeur unArraList contenant les données.

� update - retourne, si possible, la valeur de l'auto-incrément généré lorsde l'insertion.

� delete - retourne le numéro de la ligne a�ecté par cette supression

3.2.3 Module de gestion de pro�l

Par souci de clarté, le module est semblable à un module pro�l classiqueque l'on pourrait trouver sur n'importe quel site internet.

A�n de permettre à l'utilisateur de maintenir à jour les informations per-sonnelles le concernant nous avons développer un module de gestion de pro�l.

18/45


Figure 10 � Ihm du module de gestion de pro�l

Ce dernier lui permettra de changer son adresse email, son numéro de télé-phone, son nom, son prénom ou encore son mot de passe. A�n de garantirl'exactitude, ainsi que l'existence de toutes les données nous e�ectuons desvéri�cations. Ainsi, nous veillons à ce qu'aucun champ ne soit vide ou en-core a�n de valider un email nous véri�ons que celui-ci respecte la structuresuivante "[email protected]". Les champs défaillants sont mis en valeur par unchangement de la couleur du champ en rouge.Par souci de sécurité, nous utilisons notre propre classe "ValidTextBox" quiest une version de "TextBox" interdisant tous les caractères spéciaux pouvantfaciliter les injections SQL (cette classe sera utilisée pour tous les champs desaisie utilisés dans notre projet.Tous comme pour le module de connexion, ce module possède son propreservlet. Lorsque l'utilisateur valide ses changements, les informations sonttransmises au servlet correspondant. Ce dernier s'occupe d'encoder le motde passe renseigné (toujours avec la méthode MD5+ Grain de Sel), si lesmots de passe sont identiques alors les transformations sont e�ectuées dans

19/45


la base de données.

3.2.4 Le module de création de modèles

L'objectif de ce module est de permettre aux utilisateurs de créer leurspropres modèles et de les exporter en documents PDF. Les modèles sont desdocuments dynamiques s'adaptant à l'utilisateur.

L'interface se décompose en plusieurs parties.� Une liste de l'ensemble des modèles.

Figure 11 � Liste des modèles

Les modèles sont ainsi listés, il est donc possible de les charger a�n deles modi�er. L'interface client fait donc appel au servlet propre à ce modulequi se charge de lire le contenu du �chier concerné, grâce à des outils JAVAcomme Bu�erReader, et de le retourner au client. Le code du �chier est alorsa�ché au sein de la partie de création/édition.Il est aussi possible pour le possesseur du modèle de le supprimer dé�niti-vement du serveur ainsi que de la base de données. Lors de l'appel de cettefonction, le client ordonne au servlet la suppression du �chier puis supprimeles entrées concernant ce modèle dans la base de données.

20/45


� Un module de création/édition de modèle.

Figure 12 � Création/édition des modèles

A�n de permettre à l'utilisateur de créer son document, nous avons crééune partie où il dispose d'outil a�n de structurer son modèle. Pour cela il luisu�t de taper son texte au milieu de la zone prévue à cet e�et et de le mettreen forme à l'aide de la Barre d'outils. La zone de texte et un RichTextAreapermettant d'interpréter du HTML et d'ainsi visualiser la mise en forme. Labarre d'outils, ou "ToolBar" quant à elle exploite toutes les possibilités duRichTextArea en modi�ant le code HTML contenu dans la zone de texte.Une fois crée le document peut alors être "Sauvegardé" ou "Exporté".

� Les boites de dialogue de sauvegarde/exportation.

Figure 13 � Sauvegarde et exportation

Lors de la sauvegarde, la partie client demande envoi au serveur le contenudu la zone de texte. Le serveur quant à lui crée un �chier, dans le dossier"Templates", qui contiendra le contenu transmis par le client. L'ajout de cemodèle est alors e�ectué à la base de données et sera listé par la suite dans

21/45


la liste des modèles.

Pour ce qui est de l'exportation, le procédé reste identique, excepté l'écri-ture qui ne s'e�ectue pas dans un �chier classique, mais dans un �chier PDFqui est généré grâce à la librairie Itext et stocké sur le serveur dans le dossier"Documents". Le document ainsi créé est inséré à la base de données. Il seradonc listé par la suite dans l'arbre des documents.

3.2.5 Bac à sable

Le module bac à sable aussi appelé simulateur est un outil réservé auxchefs de �lières et au coordinateur des �lières. Il permet la gestion des ensei-gnants et des matières à enseigner en prenant en compte le nombre d'heure àattribuer. Ce nombre d'heure est mesurée en HEQTD, c'est à dire en heureéquivalent travaux dirigés (TD). En e�et, une heure de cours magistral (CM)n'a pas le même coe�cient qu'une heure de travaux pratiques (TP). On peutrésumer ces équivalences avec les deux équations suivantes :

60 minutes CM = 110 minutes TD

60 minutes TP = 40 minutes TD

La vue du module d'un chef de �lière et celle d'un coordinateur di�èrenttrès peu, les schémas étudiés seront ceux visibles par le responsable de �lière.

Le bac à sable se lance avec pour données, les informations de la base dedonnés.Ce simulateur possède deux facettes symétriques. Soit à partir d'une liste dematières on sélectionne l'enseignant ou bien à partir d'une liste de professeurson sélectionne la matière à enseigner. Le bouton Inverser permet de jonglerentre ces deux facettes du module sans pour autant modi�er les précédentesattributions. Le bouton Recommencer, comme son nom l'indique permet derevenir à zéro, c'est à dire de recharger la base de données. Comme aucunemodi�cation ne peut être e�ectuée par un responsable de �lière, le modulerevient donc au début. Un panneau a�che la liste des matières d'une �lière,lors de la selection de l'une d'elles, un deuxième panneau contenant les dif-férents enseignants apparait alors. Ce tableau est divisé en trois parties. Enpremier lieu, les professeurs qui enseignent la matière puis viennent les pro-fesseurs qui peuvent enseigner la matière et en�n le reste des enseignants. Unchamp de texte au dessus du panneau permet une recherche rapide parmisles ceux-ci.

Pendant l'exportation, un �chier HTML se génère et s'a�che. Il s'agit ducode HTML d'une �che étape préparatoire contenant un récapitulatif de la

22/45


Figure 14 � Bac à sable

simulation.

Après avoir sélection une concordance (enseignant → matière ou matière→ enseignant), une boite de dialogue apparait pour e�ectuer des changementéventuels sur les horaires concernées.

Figure 15 � Boite de dialogue du Bac à sable

Dans cette fenêtre s'a�che le reste des heures à attribuer pour un en-seignant et une matière. Lorsque le nombre d'heures dépasse le nombre au-torisé, il devient rouge. Comme expliqué précédemment, le nombre d'heuresrestantes à attribuer à un enseignant a�ché dans la troisième colonne est

23/45


exprimé en HEQTD ce qui permet d'avoir un rendu global sur l'attributionhoraire. Par défaut, un enseignant pouvant enseigner un matière aura tousses champs réduits à '0' et à � (chaine vide) s'il fait partie de la catégorie(Autres enseignants).

3.2.6 L'arbre des documents et le visionneur

A�n de faciliter l'accès aux documents ainsi que leur classement, nousavons développé un arbre de documents. Cependant, seuls les documents ap-partenant aux matières enseignées par l'utilisateur sont disponibles. L'arbredes documents est structuré comme suit :

� Filière 1� Matière 1� Document 1� Document ...

� Matière 2� Matière ...

� Filière 2� Filière ...

De plus, a�n de visualiser l'ensemble des documents nous avons développéun module de visualisation des documents PDF.

24/45


Figure 16 � Module de visualisation

Pour cela, lorsqu'un document est sélectionné dans l'arbre, il est automa-tique ouvert dans le visionneur qui permet d'ouvrir plusieurs documents etde changer facilement entre ces derniers. Il est aussi possible de fermer undocument ouvert. Il faut savoir que ce visionneur utilise le visualisateur PDFdu navigateur à l'aide d'une Frame.

3.2.7 Un module de partage de document

Comme expliqués précédemment, seuls les documents des matières ensei-gnées par l'utilisateur sont visibles par ce dernier. Pour cela nous avons dé-veloppé un module de partage de ces documents. L'ensemble des documents,que l'utilisateur possède, peut être partagé avec d'autres utilisateurs mêmeextérieurs à la matière. Ils seront donc visibles dans l'arbre des documents.C'est aussi grâce à ce module que les documents peuvent être supprimés.

25/45


Figure 17 � Un module de partage de document

L'interface se découpe en trois zones� Une zone qui liste tous les documents que l'utilisateur possède ainsique le bouton de suppression .

� Une zone listant les utilisateurs disponibles pour le partage.� Une zone listant les utilisateurs qui seront concernés par le partage. Ilfaut savoir que les utilisateurs disparaissent de la seconde liste aprèsvalidation du partage.

Lors de la validation de partage, les modi�cations sont e�ectuées dans labase de données.

3.2.8 Calendrier

A�n de rendre ce logiciel interactif, nous avons aussi développé un systèmed'agenda.

Ce module est composé de deux parties.� La première partie permet de consulter, supprimer ses propres événe-ments , mais aussi de gérer les événements que les autres enseignantsont partagés. A�n de consulter un événement, il su�t de sélectionnerle jour souhaité, tous les événements de ce jour seront alors listés etsupprimables.

� La seconde partie quant à elle permet la création d'événement. C'estaussi par cette interface que l'utilisateur pourra partager ses événe-ments avec d'autres utilisateurs. Pour cela, après avoir saisi l'intituléde l'événement, sélectionné sa date à l'aide du miniCalendrier et rensei-gné la description de celui-ci il sera possible de sélectionner la liste desutilisateurs avec qui le partager. L'ajout se fait de façon dynamique, ce

26/45


Figure 18 � Calendrier

qui permet de ne pas devoir recharger l'intégralité de la page.

3.2.9 Le module d'administration

A�n de faciliter l'utilisation de l'administration, nous avons décidé deséparer l'administration en trois parties.

� Une administration des utilisateurs.

Figure 19 � Une administration des utilisateurs

Cette interface permet à l'administrateur, uniquement, de créer un uti-lisateur. Il lui faudra renseigner alors le nom, le prénom, le statut ainsi quele quota horaire de l'utilisateur. Son identi�ant sera généré en suivant lestructure suivante : xXXXXXXX soit la première lettre du prénom suivie dunom. Le mot de passe est aussi généré, et est par défaut l'identi�ant. Nousconseillons vivement les utilisateurs à modi�er rapidement leur mot de passedans le module Pro�l prévu à cet e�et.L'administrateur pourra aussi modi�er les informations d'un utilisateur exis-

27/45


tant. Pour cela, il lui su�t de sélectionner un utilisateur dans la liste, toutesles informations concernant cet utilisateur seront donc chargées dynamique-ment et modi�ables.Par soucis de sécurité, le cryptage du mot de passe s'e�ectue du côté serveur.

� Une administration des �lières.

Figure 20 � Administration des �lières

Tout comme pour l'administration des utilisateurs cette partie n'est acces-sible uniquement qu'à l'administrateur. Ce module permettra au responsablede supprimer une �lière, mais aussi d'en créer une nouvelle. Pour cela, il luisu�ra de renseigner le nom et le code de la �lière, l'insertion ou la suppres-sion sera donc e�ectuée dans la base de données et l'interface sera mise à jourdynamiquement. Notre module permet aussi de modi�er le nom ou le codede la matière, mais surtout de gérer les matières appartenant à cette �lière.

28/45


� Une administration des matières.

Figure 21 � Administration des matières

Pour cette troisième partie du module d'administration, nous avons dé-veloppé un module de gestion des matières. C'est grâce à ce module quel'administrateur pourra créer ou supprimer des matières. Mais aussi d'éditerles matières existantes en précisant le volume horaire de chaque partie :

� CM : Cours magistraux.� TP : Travaux pratiques.� TD : Travaux dirigés.

L'administrateur devra également préciser le nombre de groupes partici-pants pour chaque partie.

3.3 Le déploiement

Pour l'utilisation de ce logiciel, l'installation d'une base de données sousPostgreSQL est indispensable. Cette base de données doit contenir une tablenommée "IGD" qui contiendra l'ensemble des informations de notre logiciel.La structure de la base de données est dé�nie dans le script create.sql. Actuel-lement, nous fournissons une archive ".war". A�n de faciliter l'installation,il vous su�t de copier cette archive dans votre dossier "Webapp" de votretomcat. L'installation se fera automatiquement. Par des soucis de sécurité,tomcat devra utiliser le protocole SSL.

Il su�ra alors au client de rentrer l'adresse du serveur suivit du dossier/IGD/. (https ://adresseDuServeur :port/IGD/).

Cependant, nous avons convenu, avec le client, que le deploiement sur leserveur sera e�ectué lors de la semaine du 24 janvier.

29/45


Conclusion

Tout au long de ce projet, nous avons tenté de répondre au mieux auxattentes des utilisateurs �naux et du client. Notre principale attention fûtde faire correspondre notre programme aux di�érents points abordés par lesujet, mais aussi lors des réunions de mise au point du cahier des charges. Lesystème de modules mis en place a permis à la fois au groupe de travaillerrelativement indépendamment les uns des autres, mais aussi au projet deprendre une dimension modulaire loin d'être inintéressante pour l'évolutionfuture du programme.

Même si le logiciel répond point par point aux dé�nitions données par leclient, il est fort possible que ce projet soit amené à être repris et amélioré,pour répondre à besoins futurs. Notre soucis, que ce soit lors de la conceptionou pour le choix des technologies, a été de rendre ceci le plus aisé et le plustransparent possible.

En�n du point de vue purement interne au groupe, nous nous sommesconfrontés à tous les problèmes inhérants au travail collectif et à l'organisa-tion. La productivité et le rendement n'ont pas toujours été idéaux, du faitdu manque d'expérience du groupe face à ce genre de situation. Nous avonstous des leçons à en tirer, pour nous permettre d'en ressortir plus grand.

30/45


Annexes gestion de projet

Nous allons ici présenter la partie gestion de projet qui, au dela de l'as-pect technique de l'exercice, met en oeuvre des compétences diverses tellesque le relationnel, l'organisation, le travail de groupe.

Tout d'abord, nous avons tenté d'instaurer une hiérarchie dans ce groupe.Ce fût principalement pour pouvoir prendre des décisions rapidement pourque le projet puisse suivre son cours et progresser comme prévu. Pour cela,nous nous sommes attribué des rôles (par vote à main levée pour le chef deprojet, puis par a�nités pour les autres responsabilités) qui auront quelquepeu évolués tout au long du projet. En e�et, nous avons gagné en expérienceet avons commis des erreurs qui nous ont permis de nous aguérrir.

L'organisation du projet s'est faite comme suit :

L'organigramme du projet

Les retours des audits ont permis une amélioration constante de notre

31/45


gestion de groupe, grâce à une remise en question du groupe, de nos com-pétences et des objectifs à atteindre. La mise à jour des documents, souventfastidieux à produire, a assuré une communication plus aisée avec l'auditeur,qui a pu détecter les problèmes de gestion au plus vite.

Le client, qui comme son nom l'indique passe commande auprès de notreéquipe, nous a posé ses contraintes pour la création du logiciel. Que ce soit auniveau des fonctionnalités, des technologies à utiliser, de la direction généraledu projet, nous avons reçu des consignes lors des réunions incluant parfoisles principaux utilisateurs �naux.

Le directeur des ressources humaines a eu pour rôle de former le groupe,de résoudre les problèmes intrinsèques à l'équipe.

Pour ce qui est de l'organisation interne du groupe, les rôles ont été ré-partis comme indiqués dans le Plan Assurance Qualité également en annexe.Même si les responsabilités ont transité lors de ces deux mois, les fonctionssont restées les mêmes :

� Le chef de projet : il a pour but de prendre les décisions pour le biendu projet. Il doit également tenter de garder la cohésion du groupe.

� Le responsable communication : il s'attache à la bonne communicationinterne et externe au groupe.

� Le responsable production : il est responsable des délais sur les livraisondu produit et de son déploiement.

� Le responsable base de données : comme son nom l'indique, il est res-ponsable de l'évolution de la base de données de la conception à la �nde la réalisation.

� Le responsable qualité : il rédige le PAQ et s'attache au respect ducahier des charges.

32/45


Plan d'Assurance QualitéVersion 2.0

<[email protected]>



Projet : Intranet d'administrations des enseignementsCadre : Projet Master 2 Informatique, Université du HavreProposé le : 23 novembre 2010Auteur : Laurent AmantonRéférence : http://matis.univ-lehavre.fr/Projets/index.html

Réalisation d'un intranet (langage non déterminé) permettant de gérertoute la partie administrative des enseignements à l'université. Les étudiantsdevront établir un cahier des charges en prospectant auprès des responsablesadministratifs de notre UFR puis établir les besoins auprès de di�érents co-ordinateurs de disciplines et responsables de �lières. Un site intranet seraensuite proposé pour automatiser un certain nombre de tâches.Les technologies utilisées pour ce site devront être également ré�échies, pours'adapter aux di�érents utilisateurs. Le site devra évidemment proposer unepartie administrateur et une partie utilisateur distinctes. Ajax et sqlite sontfortement conseillés a�n de rendre cet outil ergonomique, rapide et simpled'utilisation.

34/45


Quoi ?

Origine

Vu le nombre très important de documents nécessaires à la gestion du dé-partement informatique de l'Université du Havre, ainsi que tous les échangesentre enseignants, Monsieur Amanton nous a proposé de créer un intranetréunissant un ensemble d'outils pour leurs simpli�er la tâche.

Contexte du projet

Le logiciel est à concevoir dans le cadre d'un projet universitaire de Master2. Le développement se fait en parallèle des autres enseignements et l'évalua-tion entre en compte pour l'obtention du diplôme.Le projet entre dans un contexte d'automatisation des tâches de gestion d'en-seignement. A une époque où les économies passent par un gain de temps etde papier, cet outil permet une modernisation du système administratif del'Université du Havre.

Livrables du projet

� Un intranet possédant :� un tableau d'a�chage.� un système de partage de documents.� un module d'archive des documents remplis précédemment.� un module "intelligent" de mise en liaison Enseignants-Enseignements.� un module d'aide à la saisie des documents administratifs.� un calendrier d'échéances.� une administration de l'ensemble de l'intranet.

� Une documentation sur l'utilisation et l'administration.� Un code commenté et clair pour de possibles améliorations futures.� Un déploiement sur le réseau de l'Université

Limites du projet

Le projet se limite à concevoir cet outil uniquement pour les professeursd'informatique (ainsi que l'administration), mais doit être pensé pour defuturs extensions aux autres départements.

35/45


Moyens de réalisation du projet

Une équipe de 5 personnes (détaillée plus bas) ainsi que tous les moyensmatériels nécessaires pour le développement sont mis à disposition du projet.En ce qui concerne le déploiement, un serveur de test et une station pourla version �nale, tous deux connectés au réseau local de l'Université, sontfournis par le client.

36/45


Qui ?

Maîtrise d'ouvrage

- Organisme : Université du havre- Nom : Laurent Amanton- Fonction : client- Rôle : Dé�nition des besoins

Maîtrise d'÷uvre

GRPC est composé comme suit :- Baptiste Rendu : Chef de projet / Responsable Qualité / développeur- Robin Troadec : Responsable Communication / Responsable Gestiondes risques / développeur

- Roman De Oliveira : Responsable Production et déploiement / déve-loppeur

- Yassine Bakhti : développeur- Ahmim Ahmed : développeur

Communications au sein du projet

La communication se fait par l'intermédiaire d'une documentation rigou-reuse sur tous les échanges lors des réunions. Toute prise de décision lorsd'une étape importante du process se retrouve consignée dans les documentso�ciels.Cet ensemble de documents se détaille ainsi :

- Rapports de réunions- Cahier des charges- Plan d'Assurance Qualité- Rapport sur la gestion des risques

37/45


Quand ?

Cycle de vie du projet

Articulations du plan de développement

Le plan de développement du projet se découpe en phases dé�nies commesuit :

- Jalon de lancement du projet- Phase d'expression du besoin- Jalon de validation du besoin- Phase de faisabilité- Jalon du choix de la solution- Phase de développement- Phase de réalisation 1- Phase de réalisation 1.1 : Livraison des outils (Session et SGBD)- Phase de réalisation 1.2 : Livraison de la première phase de module- Phase de réalisation 1.3 : Livraison de la seconde phase de module

- Phase de réalisation 2 : Finitions et correction de bogues- Phase de véri�cation : Le responsable déploiement gère la mise en placedu serveur et des outils

- Jalon de quali�cation- Jalon de livraison

38/45


Facteurs de succès et risques liés au projetTableaudesrisquesduprojet

Intitulé

Gra

Prob

Crit

Prévention

Réparation

Projetnonterminéàla

date

43

12Travailler

surletemps

libre

Modulesnon

fonction-

nels

33

9Nepaslesincluredans

leprojet

Manquedecommunica-

tion

42

8Outils

decommunica-

tion

(mailet

svn)

+jalons

delivraison

Propagationdeladémo-

tivation

23

6Récom

penserlestra-

vailleurs

Lemanquedeconnais-

sance

23

6Partage

desconnais-

sanceslorsde

réunions

Multitudedemodules:

séparationdugroupe

22

4Des

réunions

tous

les

mardi

Travaillerseul

Gra : Gravité, Prob : Probabilité, Crit : Criticité

On évalue la gravité du risque à l'aide d'une note allant de 1 à 4. De la mêmemanière on note la probabilité que ce risque se produise.

39/45


Le produit de ces deux facteurs nous donne la criticité.

Planning général

Diagramme de Gantt

Le diagramme de Gantt ayant servi pour la répartition des tâches

Calendrier des réunions des structures du projet

Liste des réunions de la structure- 19/11/2010 : Premier rendez-vous avec le client- 23/11/2010 : Réunion d'équipe GRPC- 24/11/2010 : Premier audit- 25/11/2010 : Réunion avec le client et des responsables utilisateurs- 29/11/2010 : Réunion conception maquette- 30/11/2010 : Réunion conception UML/SQL- 06/12/2010 : Lancement de la partie Réalisation- 10/12/2010 : Second audit- 13/12/2010 : Réunion générale : redé�nition des tâches, redé�nition duplanning

Dates importantes

- 04/01/2011 : Troisième audit

40/45


- 25/01/2011 : Fin du projet- Première semaine de février : Soutenance

Calendrier des livraisons et des jalons

Jalons de livraison en interne :- Jalon de lancement du projet- Jalon de validation du besoin- Jalon du choix de la solution respecté- Jalon de développement Retard de 7 jours, manque d'implication d'unepartie de l'equipe.

- Phase de réalisation 1- Jalon de réalisation 1.1 : Livraison des outils (Session et SGBD).Retard de 3 jours, manque de travail d'un membre de l'équipe surune tâche critique (Accès base de données)

- Jalon de réalisation 1.2 : Livraison de la première phase de modules.5 modules non terminés. Désertion de certains membres de l'équipedurant plus de 2 semaines.

- Jalon de réalisation 1.3 : Livraison de la seconde phase de modules- Jalon de réalisation 2 : Finitions et correction de bogues- Jalon de véri�cation- Jalon de quali�cation- Jalon de livraisonA chaque retard prit sur le projet, les jalons sont recalculés. Cela est d'au-

tant plus di�cile que les ressources humaine disponibles sont très variantes.Les raisons observées de ces retards ont des raisons diverses expliquées ettraitées dans le document de gestion des risques V2.0.

41/45


Comment ?

Les technologies utilisées pour le développement

Système : Multi-plateforme.Technologies : Google Web Toolkit, HTML5, CSS, JavaScript, PostgreSQL.

Ressources documentaires

Technologies :� GWT : http ://code.google.com/webtoolkit/� Tomcat : http ://tomcat.apache.org/� PostgreSQL : http ://www.postgresql.org/Tutoriaux :� GWT : http ://gwt.google.com/samples/Showcase/Showcase.html

42/45


Fonctionnalités détaillées

<[email protected]>



L'intranet devra permettre aux professeurs de département informatiquede créer des documents et de les partager. Mais aussi de créer de façondynamique le feuille de répartition des enseignements.Ainsi, cet intranet comportera plusieurs modules.

Un module de connexion

Ce module permet à un utilisateur connu de renseigner son identi�ant etson mot de passe, et d'ainsi d'accéder aux fonctionnalités de l'intranet.

SimulatorTab

Ce module listera les di�érentes matières ainsi que leurs taux de remplis-sage. La sélection d'une matière permet le listing des di�érents professeursaptes à l'enseignement de celle-ci. Après le choix du professeur, il est possiblede �xer le nombre d'heures attribuées à ce dernier.Une fois l'ensemble des matières con�gurées, il est possible de sauvegarderla répartition et d'ainsi générer la feuille de répartition des enseignements auformat pdf.

Pro�leTab

Ce module permet de lister et modi�er l'ensemble des informations per-sonnelles(pro�l) d'un utilisateur.

Calendar

Ce module est un calendrier à la date du jour. Les événements sont a�chésdans le calendrier, lors de la sélection d'un jour précis, les événements de cejour sont ainsi détaillés.Lors de la création d'un événement il est possible de lui attribuer une dateprécise, un descriptif mais surtout de choisir les professeurs avec qui partagercet événement.

TemplatesTab

Un template est un document qui s'adapte à l'utilisateur. Ainsi, deschamps sont prédé�nis pour récupérer les informations de l'utilisateur cou-

44/45


rant et de les insérer dans le document.Ce module liste l'ensemble des "Templates" de l'utilisateur ainsi que les tem-plates publics a�n de les charger, les éditer et les exporter en pdf. Celui-cipermet aussi de créer des templates dynamiques et de les exporter au formatpdf(document �nal).

ShareTab

Ce module est le module de gestion des documents pdf. C'est au coeurde ce module que nous pouvons gérer le partage de ses propres documentsavec d'autres professeurs, mais aussi la suppression de documents.

FileTree

Ce module, est un arbre qui liste les documents visibles par l'utilisateurcourant selon la hiérarchie suivante : "promotion puis matière". La sélectiond'un de ces documents permet l'ouverture de ViewerTab et d'ainsi visualiserle document pdf.

ViewerTab

Ce module est donc le module nécessaire à la visualisation de tout do-cument pdf. Cette visualisation utilise "adobe reader" et donc dispose del'ensemble des fonctionnalités telles que l'impression, le zoom et la sauve-garde.

AdminTab

Ce module est le module d'administration de l'ensemble de l'intranet. Cemodule sera accessible uniquement par l'administrateur de l'intranet.Ce module permet donc de gérer les utilisateurs, leurs informations person-nelles, leurs enseignements et leurs droits. Mais aussi de gérer les di�érentes�lières ainsi que les matières composant celle-ci.

45/45