Rapport - Département Informatique

Université de Nice - Sophia-Antipolis
Faculté des sciences Valrose
28 avenue valrose, 06103 Nice
Travail d’étude et de recherche
Gestion-évaluation
semi-automatique de projets
RAPPORT
1 er juin 2011
Présenté par :
M. Albertini Ken
M. Bertrand Yoann
M. Franot Raphaël
M. Lludice Daniel
Sous la direction de :
M. Huet Fabrice

Remerciements
Nous souhaiterions remercier M. Fabrice Huet pour nous avoir proposé ce sujet de
TER. Nous le remercions également pour ses conseils, ses critiques positives et son encadrement.
Qu’il nous soit aussi permis de remercier l’ensemble des enseignants du Master Informatique
de la faculté des sciences de Valrose.

Résumé
Nous avons effectué notre Travail d’Étude et de Recherche (TER) sous la direction
de M. Fabrice Huet. Le but de ce travail était de créer un portail Web pour la gestion
et l’évaluation de projets étudiants. Comme pour tout projet informatique, nous avons
effectué un ensemble de tâches afin de répondre à la problématique. Ces tâches peuvent
être résumées en trois grandes phases :
– une phase d’analyse et de conception,
– une phase de développement,
– une phase de tests et de packaging 1 .
La première phase consistait à dresser une étude de l’existant afin de déterminer si des
projets similaires avaient déjà été développés. A partir des informations relevées, nous
avons déterminé les technologies que nous allions utiliser ainsi que la structure générale
de notre portail.
Une fois la première phase réalisée, nous avons commencé le développement de l’application
en déléguant à chacun des membres de l’équipes des tâches d’implémentation en
fonction de son niveau et de sa productivité.
Enfin, la troisième phase a permis d’effectuer des tests et de créer une documentation
pour les futurs utilisateurs de l’application.
Au niveau du pilotage du projet, nous avons définis un diagramme de GANTT que nous
avons dû modifier plusieurs fois lors du TER afin de pallier certains problèmes (manque
de temps, de compétences ou de moyens). En plus de cela, il a été décidé de définir chaque
semaine les tâches prioritaires et de faire un suivi journalier du travail attendu et du travail
effectué. Ces opérations ont globalement permis de mieux appréhender les difficultés
survenues au fur et à mesure du déroulement du projet.
A la fin de ce TER, nous avons réalisé une bonne partie des fonctionnalités demandées.
Néanmoins, il reste quelques fonctionnalités que nous n’avons pas eu le temps d’implémenter
(gestion des groupes d’étudiants et gestion des dates de rendu). Néanmoins, nous avons
développé notre application pour que celle-ci soit la plus évolutive possible, afin de donner
la possibilité à d’autres personnes de continuer notre travail.
1. Création de documentation et mise en forme du livrable.

Table des matières
1 Introduction 1
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Solution de gestion de projet . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Solution d’évaluation de code . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Choix d’implémentation 5
2.1 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Technologie Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Technologies d’évaluation de code . . . . . . . . . . . . . . . . . . 7
2.2.3 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Résultats d’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Travail effectué 12
3.1 Serveur de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Portail Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Définition des fonctionnalités . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Conception de l’IHM . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Prise en main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Conception des tables . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Remplissage et tests . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Connexions entre les différentes parties . . . . . . . . . . . . . . . . . . . 17
3.5.1 Connexion portail - Jenkins . . . . . . . . . . . . . . . . . . . . . 17
3.5.2 Connexion portail - BD . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Ajouts de fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1 Authentification et gestion des connexions au portail . . . . . . . 19
3.6.2 Gestion des groupes d’étudiants . . . . . . . . . . . . . . . . . . . 20
3.6.3 Gestion automatique des comptes FTP . . . . . . . . . . . . . . . 20
4

3.6.4 Documentation et mise en forme du livrable . . . . . . . . . . . . 21
3.6.5 Ergonomie de l’IHM . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Gestion de projet 23
4.1 Stratégie de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Évolution du planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Solutions retenues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Travail de chacun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.1 Ken Albertini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.2 Yoann Bertrand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.3 Raphaël Franot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.4 Daniel Lludice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Conclusion 28
5.1 Travail effectué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Travail restant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 Simplification de l’installation . . . . . . . . . . . . . . . . . . . . 30
5.3.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Gain de connaissances techniques . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Gain de connaissances pratiques . . . . . . . . . . . . . . . . . . . . . . . 31
6 Glossaire 32
Bibliographie 35

Chapitre 1
Introduction
Ce chapitre a pour objectif de présenter le sujet du Travail d’Étude et de Recherche
effectué par Ken Albertini, Yoann Bertrand, Raphaël Franot et Daniel Lludice. Dans
un premier temps, nous traitons de la problématique soulevée par le sujet ainsi que
des différentes fonctionnalités définies par l’encadrant. Dans un second temps, nous
présentons les principaux résultats d’une étude de l’existant que nous avons mené afin de
déterminer les solutions déjà implémentées.
1.1 Problématique
Pour un enseignant, la gestion et l’évaluation de projets étudiants peuvent s’avérer
complexes à cause d’un certain nombre de problèmes :
– non-respect des conditions de rendu (mauvais nom d’archive ou de fichiers, etc.),
– non-respect des dates de rendu,
– problèmes divers (code trop volumineux pour un simple mail, etc.),
– problèmes de fonctionnement une fois le code évalué sur la machine de l’enseignant
(architecture et système d’exploitation différents, bibliothèques manquantes, etc.).
Ces problèmes demandent à l’enseignant un temps de travail supplémentaire. Le but de
notre TER est d’essayer de réduire ce travail fastidieux en implémentant un portail Web
de gestion et d’évaluation de projets. Pour cela, le portail doit implémenter un certain
nombre de fonctionnalités, et ainsi donner la possibilité :
– de gérer des utilisateurs différents,
– de créer et de gérer des projets,
– de contrôler le rendu des étudiants (nom et format des archives, etc.),
– de centraliser la récupération des projets.
En plus de simplifier le travail des enseignants, le portail doit aussi permettre aux
étudiants de soumettre leurs projets afin que ceux-ci soient pré-évalués. Pour éviter les
abus, la soumission du code est gérée par un système de crédits, qui permet à l’étudiant
de déposer son travail un nombre limité de fois. Le nombre de crédits est fixé par l’enseignant
et peut être différent pour chaque projet. En déposant leur code tout au long
du projet (1 crédit pour une soumission), les étudiants peuvent ainsi s’assurer du bon
1

espect des conditions de rendu. Ces conditions peuvent prendre plusieurs formes, comme
par exemple :
– vérifier que le projet est implémenté dans le bon langage,
– vérifier que le projet compile,
– vérifier la présence d’une méthode ”main”,
– s’assurer que le résultat obtenu est conforme au résultat attendu.
– etc.
En résumé, l’objectif du portail est double. Dans un premier temps, il permet aux enseignants
une gestion et une récupération simplifiées des projets (récupération centralisée,
contrôle sur le nom des archives rendues, etc.). Dans un second temps, le portail octroi aux
étudiants un outil qui permet de s’assurer que leur code est conforme aux conditions de
rendu. D’autre part, on peux imaginer que si l’enseignant note les projets sur la machine
qui héberge le serveur, cela peut éviter les problèmes dues aux différences d’architectures
et de système d’exploitation (car l’enseignant et les étudiants ont la même machine de
test).
La figure ci-dessous dresse l’ensemble des fonctionnalités que le portail doit fournir :
Figure 1.1 – Tableau des fonctionnalités du portail.
2

En plus des fonctionnalités ci-dessus, le portail doit mettre l’accent sur la facilité d’utilisation
et l’ergonomie. De plus, l’application doit pouvoir évoluer, en donnant la possibilité
d’implémenter facilement d’autres fonctionnalités (protéger l’exécution des projets dans
des machines virtuelles, gestion de plusieurs promotions, etc.).
1.2 État de l’art
Cette section traite de l’étude que nous avons mené afin de déterminer si d’autres
implémentations répondaient déjà à notre problématique. Nous discutons ici de deux
points ; les applications de gestion de projets étudiant et les applications d’évaluation de
code informatique.
1.2.1 Solution de gestion de projet
Il existe un grand nombre de solutions logicielles permettant la gestion d’étudiants et
de projets à travers un portail Web 1 . Ces solutions offrent des fonctionnalités usuelles,
comme la possibilité de créer et de supprimer des personnes, de gérer des groupes ou
encore de déposer du contenu sur un serveur. Néanmoins, beaucoup de ces solutions
dépassent notre utilisation, en offrant d’autres fonctionnalités, comme la gestion d’emploi
du temps, de relevés de notes ou encore de listes de diffusion. De plus, un grand nombre
de ces solutions ne sont ni open-sources, ni gratuites.
1.2.2 Solution d’évaluation de code
Après quelques recherches, nous avons découvert deux sortes de logiciels permettant
d’évaluer 2 du code ; les logiciels d’intégration continue (IC) et les logiciels de type ”Automated
Judge System” (AJS).
Les logiciels d’intégration continue sont des logiciels utilisées dans certaines formes de programmation.
L’intégration continue permet à des développeurs de s’assurer que l’intégration
du logiciel est faites tout au long du processus de développement. Plus généralement, ces
logiciels permettent d’obtenir des résultats qualitatifs et quantitatifs d’un code donné.
Les logiciels dit ”Automated Judge System” sont utilisés lors de compétitions ou autre
rendez-vous de développeurs. Ils permettent de confronter plusieurs programmes entre
eux afin de déterminer le plus rapide, le moins gourmand en ressources ou encore celui
avec la plus petite taille. Là encore, ce type de programme permet de donner des informations
quantitatives et qualitatives.
1. D’une manière plus générale, ces logiciels traitent du personnel et du contenu (images, vidéos, etc.).
2. Par évaluer, nous entendons compiler et exécuter.
3

1.2.3 Résultats
Notre première analyse montre que notre problématique n’a jamais vraiment été soulevée.
Il existe un ensemble de logiciel permettant la gestion d’étudiants, mais ces derniers
sont souvent trop complets. De plus, ces solutions sont très souvent payantes et leurs
sources ne sont pas disponibles.
Intuitivement, les logiciels d’IC et d’AJS ne sont pas conçus pour l’utilisation que nous
voulons en faire. Néanmoins, cette première étude a permis de voir que les logiciels d’IC
répondent mieux à nos critères, car il n’est pas prévu que notre portail confronte les
projets étudiants entre eux.
4

Chapitre 2
Choix d’implémentation
Cette section traite des choix d’implémentation fait sur les différentes parties de l’application
(technologies Web, plate-forme d’évaluation et base de données). Pour chacune
des parties, nous établissons un bref récapitulatif de nos recherches, puis nous exploitons
les résultats obtenus afin de choisir les technologies les plus adéquates.
2.1 Expression des besoins
Pour pouvoir mener à bien notre projet, nous effectuons dans un premier temps un
travail de recherche sur les différentes technologies Web disponibles. Nous dressons une
liste des critères déterminants que la technologie choisie doit avoir. La liste de ces critères
est présentée ci-dessous :
– Langage déjà connu ; afin d’éviter d’apprendre un nouveau langage.
– Facilité d’implémentation ; (API, code déjà produit, bibliothèques, etc.).
– Technologie plébiscitée ; afin d’augmenter potentiellement la documentation disponible.
– Interopérabilité et évolutivité ; afin de pouvoir modifier et améliorer l’application
au fil du temps.
– Autres (ancienneté de la technologie, facilité de prise en main, etc.).
De la même manière, nous listons ensuite les caractéristiques que la technologie d’évaluation
de code doit avoir :
– gratuité,
– langage d’implémentation (en priorité Java),
– possibilité de compiler des projets implémentés dans plusieurs langages,
– utilisation de machines virtuelles 1 ,
– corrélation de code,
– mise à disposition d’une API (pour le développement de plugins par exemple),
– interopérabilité avec d’autres logiciels et protocoles (Maven, Ant, SSH, etc.)
1. Le fait d’exécuter du code sur une machine virtuelle permet d’éviter de perdre la totalité du serveur
en cas d’exécution d’un code malicieux ou bugué.
5

– documentation (installation, utilisation, javadoc, etc.),
– facilité d’installation,
– facilité d’utilisation et d’administration.
2.2 Étude comparative
2.2.1 Technologie Web
Après avoir effectué la liste des critères, nous avons sélectionné plusieurs technologies
Web.
Technologies AJAX
GWT[1] (Google Web Toolkit) est une ensemble d’outils logiciels développé par Google
permettant de produire des applications Web dynamiques en utilisant JavaScript. Son
avantage réside dans le fait que le code est produit en Java et qu’il existe de nombreuses
documentations. De plus, étant une technologie AJAX, GWT offre une grande
interopérabilité et une bonne évolutivité.
Jaxcent[2] est une alternative à GWT. Il permet lui aussi de créer des pages Web dynamiques
grâce à Java. Il est orienté serveur et permet une bonne évolutivité. Néanmoins,
la qualité de la documentation disponible est inférieure à celle de GWT.
Technologies Adobe
Flash[3] est une application client qui permet d’ajouter des animations ou des objets
interactifs sur une page Web. Facile à implémenter, Flash souffre toutefois de problèmes
d’instabilité sur plusieurs systèmes d’exploitation (Linux par exemple).
Flex[4] est une solution de développement qui permet de développer des applications
internet riches. Relativement simple à prendre en main, Flex utilise les technologies Flash,
MXML et ActionScript. Néanmoins, cette solution souffre des inconvénients de Flash.
Autres technologies
PHP[5] est un langage de scripts libre utilisé pour produire des pages Web dynamiques.
Il est relativement facile à implémenter. De part son ancienneté, il dispose de beaucoup
de documentation et de code déjà produit. Malheureusement, PHP est sujet à de nombreuses
failles de sécurité.
Silverlight[6] est une alternative à Flash développée par Microsoft. Il permet aux développeurs
d’utiliser les outils de développement et les langages Microsoft .NET afin de créer des
applications Web dynamiques fonctionnant dans un moteur de rendu vectoriel.
6

Après avoir récupérer un maximum informations, nous avons comparé ces technologies
entre elles afin de tirer les avantages et les inconvénients de chacune, comme le montre le
tableau récapitulatif suivant :
langage libre code doc. évolutif autres
connu disponible dispo. (inconvénients)
PHP oui oui oui oui non problèmes de sécurité
GWT oui(java) oui oui oui oui relativement complexe
Flex non non oui oui oui problème de stabilité
Flash non non oui oui non lourdeur
Silverlight non non oui oui oui problème de stabilité
Jaxcent oui(Java) oui oui non oui moins plébiscité que GWT
2.2.2 Technologies d’évaluation de code
Une fois les critères établis, nous avons sélectionné plusieurs logiciels d’intégration
continue et de type ”Automated Judge System”.
Logiciels d’intégration continue
Jenkins[7] (anciennement Hudson) est un serveur d’intégration continue libre et opensource
(écrit en Java). Il peut fonctionner dans un conteneur de servlets tel que Tomcat
et peut être interfacé avec d’autres technologies (SVN, CSV, Maven, Ant, etc.). Il dispose
aussi d’une API de développement de plugins permettant d’ajouter des fonctionnalités.
Étant relativement plébiscité dans le domaine de l’intégration continue, Jenkins dispose
d’une bonne documentation et d’un grand nombre d’utilisateurs. De plus, Jenkins peut
compiler et exécuter des programmes de langages différents (Java, C, C++, Python, Php,
etc.).
Bamboo[8] est un logiciel d’intégration continue payant qui dispose de plusieurs plugins
pour ajouter des fonctionnalités qui peuvent être intéressantes dans notre cas d’utilisation
(gestion approfondie des tests par exemple). Il est développé en Java, mais les sources ne
sont disponibles qu’après achat de l’application. Néanmoins, il est capable d’exécuter du
code développé dans des langages comme Java, PHP ou JavaScript.
Continuum[9] est le serveur d’IC d’Apache. Il est libre et open-source (développé en Java).
Il dispose d’une bonne documentation et permet d’être interfacé avec d’autres technologies
(Ant, Maven, CSV). Il est également capable de compiler des programmes C, C++
et Java. Néanmoins, quelques fonctionnalités sont manquantes, comme la corrélation de
code ou la possibilité de supporter des machines virtuelles.
7

Logiciel de type ”Automated Judge System”
Mooshak[10] est une solution logicielle qui permet d’évaluer les performances de plusieurs
codes entre eux. Il est spécialisé pour des compétitions de type ICPC (International Collegiate
Programming Contest). Il utilise des machines virtuelles pour effectuer des tests
et supporte des langages comme C, Pascal, C++ ou Java.
DOMJudge[11] est un concurrent de Mooshak qui offre une interface Web permettant
au jury, aux compétiteurs ou au public de visualiser les résultats des compétitions. Ces
résultats sont modulables et l’application est conçue pour être ergonomique et légère.
Comme les autres solutions citées précédemment, DOMJudge peut compiler et exécuter
du code C, C++ et Java.
Code-cracker[12] est un système libre qui donne la possibilité de faire de la corrélation de
code. Malheureusement, il n’existe pas beaucoup de documentation pour cette solution
logicielle.
Comme pour les technologies Web, nous dressons ensuite un tableau récapitulant les fonctionnalités
des principales solutions logicielles trouvées.
libre langage compilation de machines corrélation
d’implémentation de plusieurs langages virtuelles de code
Jenkins oui java oui oui non
Mooshak oui python oui oui non
DOMJudge oui php oui non non
DWite non visual basic oui oui non
Code-cracker oui c++ oui - oui
Bamboo oui java oui oui -
API documentation interopérabilité autres avantages
de dev. disponible
Jenkins oui oui Ant, Maven, plébiscité, 300 plugins
VMware, VirtualBox facilité d’installation
Mooshak non oui LDAP, ssh bonne flexibilité
DOMJudge non oui SSH, NFS, SCP plusieurs plugins
DWite non non SSH léger
Code-cracker non non CSV -
Bamboo oui oui Maven, Ant plusieurs plugins
Continuum oui oui Maven, Ant développé par Apache
2.2.3 Base de données
Une fois les deux analyses précédentes effectuées, nous avons réfléchi à la nécessité
d’utiliser une base de données. Pour répondre à cette question, nous avons listé dans un
8

premier temps les entités manipulées, afin de savoir s’il y avait un quelconque avantage
à les rendre persistantes.
Voici la liste des entités que notre portail doit pouvoir gérer :
– des utilisateurs aux profils différents (administrateurs, enseignants, étudiants),
– des données (projets soumis, batteries de tests),
– des macro-entités (promotions d’étudiants, groupe de projet, etc.).
Une fois cela fait, nous avons considéré qu’il était effectivement judicieux d’utiliser une
BD dans notre application. Nous avons alors effectué une étude comparative des différents
modèles de base de données, afin de décider quelle technologie nous allions utiliser.
Base de données orientée texte
Une base de données orientée texte (ou Flat File database en anglais), est une base de
données contenue dans un seul fichier texte. On utilise ce type de base de données pour
des systèmes embarqués ou pour des implémentations ne nécessitant pas d’enregistrer des
volumes d’informations trop complexes.
Base de données relationnelle
Une base de données relationnelle stocke les informations dans des tables. Ces tables
sont régis par des règles d’algèbre relationnelle, qui permettent d’interagir avec la base
de données grâce à des requêtes. Les base de données relationnelles apportent un certain
nombre d’avantages :
– une bonne scalabilité.
– une facilité pour spécifier des contraintes d’intégrité sans programmation.
– une théorie solide et des normes reconnues.
– un langage d’interrogation puissant.
– etc.
Base de données orientée objet
Une base de données orientée objet permet de stocker les informations sous forme d’objets.
Utilisant le langage objet Java (via notre implémentation en GWT), nous pouvons
facilement justifier que dans la mesure ou nos entités sont des objets du coté du portail, il
peut être judicieux d’utiliser une base de données objet, afin d’éviter le mapping (transformation)
d’objets Java en autres types de données (texte pour les Flat File database ou
des tuples pour une base de données relationnelle).
Autres modèles de bases de données
Il existe d’autres modèles de bases de données, comme par exemple les bases de données
XML ou objet-relationnel. Ces dernières ne semblant pas adéquates pour notre utilisation,
nous avons décidé de ne pas les étudier.
9

2.3 Résultats d’étude
2.3.1 GWT
En vue de cette étude, notre choix s’est rapidement porté sur GWT pour plusieurs raisons.
Tout d’abord, GWT dispose d’une bonne documentation (javadoc, tutoriels, forum, etc.).
Ensuite, ce dernier permet de mettre en œuvre du JavaScript en codant du Java, nous
n’avons donc pas à apprendre un langage supplémentaire. Enfin, cette technologie peut
s’interfacer avec d’autre éléments grâce à des mécanismes de type RPC, et peut facilement
être déployé 2 .
En revanche, le principal inconvénient de GWT est sa complexité ; ce dernier nécessite en
effet un temps d’adaptation conséquent. Nous avons considéré que cet inconvénient était
un des prix à payer pour ne pas avoir à apprendre un langage supplémentaire (comme
PHP ou Flex) et pour avoir accès à une documentation de bonne facture.
2.3.2 Jenkins
En vue des résultats, notre choix s’est porté sur Jenkins. En effet, de tout les logiciels
étudiés, Jenkins est celui qui correspond le mieux à nos attentes (gratuit, développé en
Java, bonne documentation, fonctionnalités modulables via des plugins, gestion de plusieurs
langages différents, facilité d’utilisation, etc.). De plus, Jenkins peut lui aussi être
intégré dans un serveur Tomcat. Malheureusement, Jenkins ne dispose pas nativement
de toutes les fonctionnalités requises (pas de gestion de corrélation de code par exemple).
Néanmoins, ce manque peut être comblé par l’implémentation d’un plugin, en utilisant
l’API idoine.
2.3.3 MySQL
Pour des raisons d’évolutivité, nous avons décidé de ne pas utiliser une BD de type Flat
File. En effet, si dans le futur le portail implémente d’autres fonctionnalités (gestion
administrative des étudiants par exemple), une base de données de ce type pourrait ne
pas répondre efficacement à nos attentes à cause d’une trop grande complexité. Le portail
se voulant évolutif, nous avons décidé de ne pas retenir ce type de base de données.
De la manière, nous avons décidé de ne pas choisir les bases de données orientées objet
car nous n’avons pas besoin de rendre les objets du portail persistants.
Nous avons donc décidé de gérer nos entités via une base de données relationnelle, car ce
modèle nous est le plus familier et qu’il offre les avantages cités précédemment.
En ce qui concerne le Système de Gestion de Base de Données (SGBD) utilisé, notre choix
s’est porté sur MySQL, car ce logiciel est léger, open-source, fiable et très utilisé. De plus,
MySQL est complètement compatible avec Java 3 , ce qui permet d’éviter un maximum
les problèmes d’interfaçage entre la base de données et le portail.
2. On peut par exemple générer un fichier .war et l’uploader directement dans un serveur Tomcat
3. Le driver (JDBC), faisant la connexion entre Java et MySQL a d’ailleurs été étudié dans un module
de M1.
10

Nous avons vu dans cette première partie les différents choix technologiques que nous
avons fait. Ces choix ont été effectués à partir d’études préliminaires visant à déterminer
les solutions répondants le mieux à nos critères.
Nous avons choisi de répondre à la problématique de ce TER en utilisant les technologies
suivantes :
– GWT pour le portail Web,
– Jenkins pour la structure d’évaluation du code,
– MySQL pour stocker les entités (utilisateurs, projets etc.)
De plus, nous avons vu que GWT et Jenkins peuvent facilement être intégrés à Tomcat.
De ce fait, nous avons décidé d’utiliser ce container de Servlets. Le schéma suivant donne
un premier aperçu de l’architecture globale de l’application.
Figure 2.1 – Vue globale de l’architecture de l’application.
11

Chapitre 3
Travail effectué
Dans ce chapitre, nous expliquons le travail effectué d’un point de vue technique. Nous
traitons ici des différentes méthodes d’implémentation et outils utilisés pour mener à bien
notre projet. Ce chapitre se décompose en six axes. Le premier est un récapitulatif du
serveur que nous avons utilisé pour nos tests. Les trois suivants traitent du travail effectué
sur chacune des trois parties de l’application (portail Web, Jenkins et base de données).
Le quatrième axe décrit les implémentations effectuées pour relier les différentes parties
entre elles. Enfin, le dernier axe décrit les fonctionnalités ajoutées et la documentation
produite.
3.1 Serveur de test
Nous avons utilisé une machine personnelle pour effectuer nos tests d’implémentation.
Cette machine a été configurée pour pouvoir être accessible depuis Internet. Nous avons
pour cela mis en place un DNS 1 et nous avons configuré le routeur et le firewall de la
machine. Le serveur a ensuite accueilli l’ensemble des outils et applications utilisées par
notre portail. Voici les caractéristiques de la machine de test :
– processeur : Intel(R) Pentium(R) 4 CPU 1.80GHz
– mémoires : 512 Mo
– système : Fedora 14 ”Laughlin”
3.2 Portail Web
3.2.1 Définition des fonctionnalités
Pour bien séparer les traitements, nous considérons trois types d’utilisateurs différents :
– l’administrateur,
– les enseignants,
– les étudiants,
1. Domain Name System
12

La différence entre les trois types d’utilisateurs réside dans le nombre de fonctionnalités.
En effet, un administrateur possède toutes les fonctionnalités des enseignants et des
étudiants. Un enseignant, quant à lui, possède des fonctionnalités supplémentaires par
rapport à un étudiant. En résumé, nous pouvons dire que l’ensemble des fonctionnalités
d’un type est un sous-ensemble des fonctionnalités du type supérieur.
3.2.2 Conception de l’IHM
Une fois les fonctionnalités définies, nous avons rapidement fait un prototype de l’interface
du portail Web afin d’avoir un premier aperçu. Pour ce faire, nous avons utilisé le
logiciel FlexBuilder (un IDE pour développer en Flex) car ce dernier permet de réaliser
rapidement des interfaces graphiques grâce à un éditeur 2 . Le fait que le langage soit du
Flex n’est pas dérangeant dans la mesure ou nous voulons simplement avoir un rendu
graphique, si possible plus pertinent et agréable que de simple dessin.
Cette conception a montré que la plupart des menus pouvaient être conçus selon le même
principe. Nous avons donc décidé d’utiliser des onglets pour séparer les menus en fonction
des entités (un onglet pour gérer les projets, un onglet pour les enseignants, etc.). De ce
fait, un utilisateur n’est pas submergé par les informations lors de sa connexion. De plus,
nous avons décidé d’utiliser des listBox pour lister les entités (enseignants, étudiants,
etc.), afin de toujours avoir une vision assez globale du système. La figure suivante donne
une idée du rendu obtenu :
Figure 3.1 – Prototype de l’IHM pour la vue ”enseignant”, vue par un administrateur.
Du point de vue de l’ergonomie, nous avons essayé de garder la même logique 3 quel que
soit le profil utilisateur. Nous avons décidé de faire cela pour qu’une personne ayant deux
comptes aux profils différents (un administrateur qui est aussi enseignant par exemple)
n’ait aucunes difficultés à passer d’un compte à l’autre.
2. Cet éditeur permet de disposer graphiquement des boutons et des menus avec la souris.
3. Nous entendons par logique la disposition des éléments (boutons, menus, etc.) dans l’interface.
13

Ce prototype a aussi permis de faire la liste des widgets GWT (boutons, listBox, onglet,
etc.) que nous allions utiliser, afin de commencer à les étudier.
3.2.3 Implémentation
Une fois le prototype défini, nous avons développé le portail en fonction de ce dernier.
Pour ce faire, nous avons utilisé des tutoriels mis en lignes par Google pour nous aider
dans notre démarche. D’un point de vue architectural, notre application Web se compose
de deux parties :
– une partie client, qui contient l’IHM et les interfaces.
– une partie serveur, qui contient les classes effectuant le traitement.
Dans un premier temps, nous avons implémenté le coté client pour avoir rapidement un
squelette (menu, boutons, onglets) de l’application. Ce squelette a permis d’avoir une
base sur laquelle greffer d’autres fonctionnalités d’une manière itérative.
3.3 Jenkins
3.3.1 Prise en main
Jenkins permet la création de ”jobs”, qui sont représentés sous la forme d’un espace
disque (ou workspace et d’un fichier de configuration (config.xml). L’espace disque sert
à stocker sur le serveur le code à compiler (un .c par exemple). Le fichier config.xml,
quant à lui, permet de spécifier le travail à effectuer lorsque l’on demande l’exécution
du job. Le fichier de configuration peut contenir par exemple des commandes Bash, qui
seront exécutées à chaque fois que le serveur reçoit l’ordre d’exécuter (ou ”builder”) le
job en question. Une fois le job exécuté, les résultats de l’exécution sont stockés dans le
workspace, permettant de ce fait de garder une trace des précédents builds.
Le but de cette prise en main a permis de comprendre le fonctionnement de l’application,
mais aussi d’en déterminer les limites et les faiblesses. Par exemple, nous avons déterminé
que même si Jenkins possède une interface web (voir figure 3.2), il est possible d’interagir
avec le serveur pour manipuler un job à distance 4 .
4. Il est ainsi possible de créer, supprimer et compiler un job. Il est aussi possible de récupérer les
résultats d’exécution après une compilation, de recevoir les résultats de la console, etc.
14

Figure 3.2 – Interface Web de Jenkins.
3.4 Base de données
3.4.1 Conception des tables
La première version de la BD contenait une table pour chaque entités (administrateurs,
enseignants, étudiants, groupes, projets) et utilisait une table pour les unir via
leurs clés primaires.
Après réflexion et confrontation des idées, il s’est avéré qu’une unique table Personnes
allait mieux convenir pour réunir les trois types d’utilisateurs, car ces derniers sont
schématisés avec plus ou moins les mêmes informations (un nom, un prénom, une adresse
email, etc.). De plus, nous nous sommes rendu compte que pour certaines fonctionnalités
(l’authentification pour se connecter au portail par exemple), la multiplication de tables
induit une multiplication des appels à la BD.
Une fois le travail terminé, nous avons obtenu les tables suivantes :
– ”Personne” ; qui définit un utilisateur (administrateur, enseignant ou étudiant).
– ”Projet”, qui définit un projet (exemple : projetXML).
– ”Groupe” 5 , qui constitue un ensemble d’étudiants.
– ”Association”, qui lie les 3 tables précédentes.
3.4.2 Remplissage et tests
La conception précédente nous a donné un ensemble de tables (Personne, Groupe,
Projet et Association). Malheureusement, le remplissage de ces dernières a soulevé un
5. Afin de ne pas confondre les groupes d’options avec les groupes d’étudiants, nous appelons ”multinômes”
les groupes d’étudiants (monôme, binôme, etc.).
15

ensemble de problème concernant la table Association. Pour pallier ce problème, nous
avons découpé Association en plusieurs tables :
– AssociationProjetGroupe ; qui lie un projet à un ou des groupes.
– AssociationProjetFichiers ; qui lie un projet aux éventuels fichiers de tests apportés
par l’enseignant pour ce projet.
– AssociationGroupePersonne ; qui lie un groupe à une ou n personnes.
– AssociationGroupeFichiers ; qui ≪ conserve ≫ les fichiers qu’un groupe soumet a la
compilation.
– AssociationEnseignantProjet ; qui permet à plusieurs enseignants d’être associés à
un projet 6 .
La figure suivante représente la structure finale de la base de données :
Figure 3.3 – Structure de la base de données.
Une fois la structure principale mise en place, nous avons remplis les tables avec quelques
tuples afin de pouvoir effectuer des tests. Ces tests ont permis de soulever certaines choses
tel que :
6. Fonctionnalité non-utilisée pour l’instant.
16

– un problème avec les clés primaires mal ciblées par les clés étrangères,
– un problème d’unicité et d’indexation.
Ces problèmes mineurs n’ont pas nécessité de refaire la conception de la base, mais ont
permis de s’assurer de la bonne intégrité des tables.
3.5 Connexions entre les différentes parties
3.5.1 Connexion portail - Jenkins
Comme nous l’avons vu précédemment, Jenkins peut être appelé à distance. Pour ce
faire, il existe deux technologies. La première est une API offerte par Jenkins, dont le
but est d’offrir un ensemble de méthode pour implémenter les fonctionnalités du serveur
d’intégration continue dans un programme Java.
La deuxième technologie consiste à utiliser des méthodes HTTP (HTTPMethod de type
POST ou GET). Ces méthodes contiennent des ordres qui sont passés directement au
serveur Jenkins.
Nous avons décidé d’utiliser les méthodes HTTP. Pour cela, nous avons implémenté une
servlet 7 qui utilise des requêtes HTTP en spécifiant l’URL de Jenkins. De cette façon, il
est possible de manipuler des jobs (création, suppression ou modification) et de récupérer
des informations sur ces derniers (dernière compilation réussie, résultat de la console,
etc.). La servlet étant exécuté via le portail, on s’affranchi ainsi de l’interface graphique
de Jenkins. La figure suivante permet de mieux comprendre le fonctionnement de cette
servlet :
Figure 3.4 – Fonctionnement d’une servlet dialoguant avec Jenkins.
Avec cette première implémentation, la servlet de communication à Jenkins n’était pas
7. Une servlet est une classe Java qui permet d’ajouter des fonctionnalités à un serveur.
17

encore en mesure d’envoyer du code (.c ou .java par exemple). En effet, pour faire cela,
il faut utiliser un protocole de transfert de fichier (le protocole HTTP n’étant pas prévu
pour cela).
Utilisation d’un FTP
Pour pouvoir envoyer du code à Jenkins, nous avons utilisé le protocole FTP. Pour ce faire,
nous avons développé une servlet qui effectue des connexions à vsftp, un serveur FTP sur
Linux. Le problème d’une connexion FTP est qu’elle nécessite le plus souvent le login et
le mot de passe d’un utilisateur Unix (root par exemple). Nous avons donc paramétré
vsftp pour que ce dernier accepte les utilisateurs de la base de données. De de fait, un
utilisateur logué sur le portail peut envoyer son code au serveur en étant automatiquement
authentifié. Cette procédure permet de ne pas transformer les utilisateurs contenus dans
la BD en utilisateur Unix.
Liaison FTP - Jenkins
Une fois le code déposé sur le FTP, le serveur déclenche la servlet qui dialogue avec Jenkins
(figure précédente). Cette dernière se charge de créer un job et d’indiquer à Jenkins le
chemin du fichier récemment uploadé. Jenkins récupère le fichier, le compile et l’exécute,
puis transmet le résultat à la servlet. Cette dernière propage alors le résultat au portail
qui l’affiche à l’utilisateur.
3.5.2 Connexion portail - BD
Nous avons aussi utilisé une servlet pour communiquer avec la base de données. Cette
servlet utilise un driver JDBC 8 ) pour se connecter à MySQL.
Une fois la connexion établie, il est possible d’effectuer un traitement sur la BD. Nous
avons décidé d’implémenter différents traitements à partir de l’IHM du portail. Ces traitements
regroupent par exemple :
– la possibilité de créer/modifier/supprimer des utilisateurs (enseignants, étudiants,
etc.),
– la possibilité de créer/modifier/supprimer des projets,
– la possibilité de visualiser les informations des différentes entités (projets, utilisateurs,
etc.),
– etc.
L’annexe 2 présente deux exemples d’interrogation de la base de données via des requêtes
SQL.
Lorsqu’un utilisateur déclenche un événement qui doit modifier la BD, le portail demande
à la servlet d’effectuer le traitement. La servlet s’exécute en déclenchant la bonne requête
SQL qui a été pré-remplie avec les valeurs spécifiées par l’utilisateur. Par exemple, dans
le cas d’une création d’un enseignant, la servlet déclenche une requête SQL en passant en
paramètre les informations spécifiées par l’utilisateur (nom de l’enseignant, prénom, etc.)
8. Java DataBase Connectivity
18

Une fois la requête exécutée, la servlet reçoit une réponse de la BD. Cette réponse transite
jusqu’à la partie cliente du portail. En fonction de cette réponse, l’utilisateur reçoit un
message qui atteste de la réussite ou de l’échec de la création d’un nouvel enseignant. La
figure suivante montre le fonctionnement d’un appel à la BD via le portail Web :
Figure 3.5 – Exécution d’une requête SQL de création d’utilisateur à partir du portail
Web.
3.6 Ajouts de fonctionnalités
3.6.1 Authentification et gestion des connexions au portail
Nous avons vu que chaque type d’utilisateur possède son propre jeu de fonctionnalités.
Ces fonctionnalités sont regroupés dans des pages (pageAdministrateur, pageEtudiant,
pageEnseignant), qui sont des classes Java regroupant les widgets (boutons, onglet, etc.)
ainsi que les appels aux servlets. Pour pouvoir faire en sorte que chaque utilisateur se
connecte sous sa propre page en fonction de son profil, nous avons décidé d’implémenter
un mécanisme d’authentification à l’entrée de l’application.
Nous avons développé une servlet qui vérifie la présence ou non de l’utilisateur dans la
base de données. Le résultat de la requête permet de charger une des pages en fonction
du profil de l’utilisateur.
Malheureusement, cette première version n’était pas suffisante, car le mot de passe de
l’utilisateur transitait en clair sur le réseau. Nous avons donc ajouté une méthode de
cryptage md5. Cette méthode crypte localement le mot de passe en une chaîne alphanumérique
de 32 caractères, puis l’envoie à la base de données 9 . Cette dernière compare
alors le login et le mot de passe crypté. Si le résultat de la requête est vide, cela veut
9. Cette technique est couramment utilisée par les personnes voulant utiliser des mots de passe cryptés
avec GWT
19

dire le couple login/mot de passe n’est pas correct, l’utilisateur est donc invité à réitérer
sa tentative de connexion. En revanche, si le résultat de la requête n’est pas vide, la
méthode d’authentification récupère dans la base le profil de l’utilisateur et charge la
page correspondante (pageEnseignant si le couple login/mot de passe spécifié appartient
à un enseignant, etc.). La figure suivante montre l’algorithme derrière le mécanisme d’authentification
au portail :
Figure 3.6 – Mécanisme d’authentification au portail Web.
3.6.2 Gestion des groupes d’étudiants
Un projet pouvant être effectué par plusieurs étudiants, nous avons décidé de donner
la possibilité au portail de gérer les groupes (binômes, trinômes, etc.) d’étudiants. Par
manque de temps, nous n’avons pas eu le temps d’implémenter complètement cette fonctionnalité.
Néanmoins, nous avons construit l’application de façon à ce que cette dernière
puisse accepter facilement la gestion des groupes. En effet, nous avons créé la vue permettant
à un enseignant de créer et modifier les groupes pour un projet donné, ainsi que
les tables de la base de données pour accepter une telle implémentation.
3.6.3 Gestion automatique des comptes FTP
Chaque utilisateur du portail possède son propre espace sur le serveur FTP. Pour
créer ces espaces automatiquement, nous avons implémenté une classe dont le but est de
créer un répertoire personnel pour chaque utilisateur de la table ”Personne”. Cette classe
se charge aussi d’affecter des droits particuliers aux utilisateurs. Ainsi, chaque étudiant
est automatiquement monté dans son répertoire personnel, sans avoir la possibilité de
voir les dossiers des autres étudiants. En revanche, les enseignants et l’administrateur ont
la possibilité de voir les répertoires des étudiants.
20

3.6.4 Documentation et mise en forme du livrable
Un des points importants de notre TER était de faire quelques choses de facilement
utilisable et compréhensible par d’autres personnes. Pour ce faire, nous avons attaché un
soin particulier à la rédaction de la documentation et à la mise en forme de l’application
dans sa version finale.
Documentation utilisateur
Pour rendre l’application plus ergonomique, nous avons écrit une documentation utilisateur
expliquant le fonctionnement du portail. Cette documentation est déclinée en
plusieurs versions (une par type d’utilisateur). Elle permet de comprendre comment utiliser
les fonctionnalités de l’application. L’annexe 1 permet de voir à quoi ressemble cette
documentation utilisateur.
Mise en forme du livrable
Une fois le code nettoyé et commenté, nous avons créé un fichier .war contenant notre
portail. Ce fichier peut simplement être déposé dans un serveur Tomcat pour pouvoir
être utilisé. Néanmoins, pour que le portail fonctionne, la machine hébergeant le serveur
Tomcat doit posséder l’ensemble des applications utilisées par le portail (MySQL, vsftp,
Jenkins, etc.).
Documentation d’installation
Pour réduire la complexité d’installation des différentes applications utilisées par le portail
Web, nous avons écrit un tutoriel qui décrit les différentes étapes et technologies à installer
pour utiliser le portail. Cette documentation, plutôt technique, est réservé principalement
à l’administrateur du portail.
3.6.5 Ergonomie de l’IHM
Pour voir si l’application était ergonomique, nous avons fait tester le portail par deux
personnes. Ces utilisateurs (des étudiants volontaires), ont d’abords utilisé l’application
pendant une dizaine de minutes avant de répondre à un questionnaire de satisfaction. Ce
questionnaire est divisé en 3 parties :
– une partie A : dont le but est de noter le portail sur quelques critères.
– une partie B : dont le but est de noter les tests utilisateurs (utilité des tâches et
facilité de compréhension)
– une partie C : qui permet aux utilisateurs de donner leur avis (qualités, défauts,
fonctionnalités à ajouter, etc.)
Ensuite nous avons demandé aux utilisateurs d’exécuter quelques tâches afin de les chronométrer
pour s’assurer que les fonctionnalités étaient bien réalisables rapidement 10
10. Dans un contexte réelle d’étude d’interface, cette méthode permet de s’assurer que l’application
fait ce qu’on lui demande (efficacité) et qu’elle le fait dans un minimum d’effort (efficience).
21

La liste ci-dessous montre les quelques tâches que les utilisateurs ont effectué :
En tant qu’administrateur :
– Créer trois étudiants (nom et informations imposés).
– Modifier le prénom d’un des enseignants (prénom imposé).
En tant qu’enseignant :
– Créer un projet (nom et informations imposés).
– Uploader un jeu de tests pour ce projet (choix du fichier imposé).
En tant qu’étudiant :
– Visualiser les infos d’un des enseignants.(choix libre).
– Soumettre un code (choix du fichier imposé).
Les résultats de cette étude sont disponibles en annexe 4. Néanmoins, nous pouvons
dire ici que ces tests utilisateurs ont permis de soulever quelques problèmes comme par
exemple :
– Le manque de pertinence pour certains messages de popup (pas assez d’informations).
– La nécessité d’appuyer sur le bouton ”Afficher Infos” pour charger les informations.
– Le manque d’informations (format des dates non spécifié) dans le menu de création
d’un projet.
– Le panneau ”descriptif” d’un projet trop petit.
Il pourrait être judicieux de prendre en compte ses critiques et de modifier le code pour
pallier aux problèmes.
22

Chapitre 4
Gestion de projet
Ce chapitre traite du pilotage du TER. Nous présentons dans un premier temps les
mécanismes mis en place pour gérer le projet ainsi que le planning prévisionnel. Dans
un second temps, nous discutons de l’évolution du planning prévisionnel au fil du projet.
Nous traitons ensuite des problèmes logistiques rencontrés ainsi que des solutions retenues
pour y pallier. Enfin, la dernière partie de ce chapitre a pour but de présenter le
travail de chacun des membres du groupe.
4.1 Stratégie de pilotage
Nous avons mis à notre disposition un ensemble d’outils pour que le pilotage de notre
projet soit le plus aisé possible. Pour cela, nous avons défini un diagramme de GANTT 1
qui a permis d’avoir une représentation graphique des différentes tâches hebdomadaires
à exécuter. Nous avons aussi mis en place une politique de gestion des risques afin de
pallier à certains problèmes (manque de productivité, perte d’un membre, etc.).
En plus de cela, nous avons utilisé l’environnement de gestion de projet Assembla[13],
qui met à la disposition des développeurs plusieurs outils 2 , comme par exemple :
– un SVN,
– un site de type Wiki (pour partager des informations),
– un partage de documents éditables de type Google Docs,
– des stand’up (voir figure 4.1) qui permettent à un membre de l’équipe de dire ce
qu’il a fait ou va faire durant sa journée de travail,
– un serveur pour stocker des sauvegardes du code et des documents produits.
De plus, ne travaillant pas au même endroit, nous avons utilisé le logiciel Skype pour
communiquer entre nous. Enfin, nous avons fait des réunions hebdomadaires avec notre
tuteur afin de définir les tâches prioritaires.
1. voir annexe 3.
2. Ces outils sont accessibles directement depuis Internet.
23

Figure 4.1 – Mécanisme de stand’up.
4.2 Évolution du planning
Au fur et à mesure de l’avancement du projet, nous avons du revoir notre planning
prévisionnel. La première raison à cela est que le planning était très optimiste et ne
prenait pas en compte les difficultés de certains (problèmes de compréhension, problèmes
pour installer des applications, etc.). Néanmoins, nous avons rapidement fait face à la
situation en restructurant et en redistribuant les tâches.
4.3 Problèmes rencontrés
Nous avons rencontré plusieurs problèmes tout au long de notre TER :
– des problèmes techniques (installations et configurations des logiciels utilisés, compréhensions,
etc.),
– des problèmes logistiques (membres géographiquement distants, niveaux différents),
– des problèmes humains (départ d’un membre de l’équipe, manque de compétences).
Problèmes techniques
Notre implémentation nécessitant plusieurs logiciels différents (Jenkins, Eclipse, plugin
Eclipse GWT, Tomcat, MySQL, PhpMyAdmin, Ant, etc.), nous avons installé ces logiciels
sur nos machines. Malheureusement, certains ont eu du mal à effectuer ces étapes et cela
nous a un peu ralenti dans notre implémentation.
Problèmes logistiques
N’étant pas géographiquement au même endroit, nous avons utilisé le logiciel Skype pour
dialoguer entre nous. Ce type de communication peut être à la base d’une mauvaise
compréhension d’un ordre ou d’une explication.
24

Problèmes humains
Après quelques semaines de travail, nous avons perdu un membre du projet qui, pour des
raisons personnelles, a décidé de ne plus travailler. Ce problème a été de loin le plus difficile
à gérer car il est survenu à un moment critique (début d’implémentation) et a perduré
durant la quasi-totalité du projet. De plus, même si la gestion des risques prévoyait la
perte éventuelle d’un membre, nous n’espérions pas tomber dans ce cas de figure, de peur
de voir notre motivation et notre productivité décroître drastiquement.
4.4 Solutions retenues
Pour essayer de pallier aux problèmes énoncés ci-dessus, nous avons mis en place
un certain nombre de solutions. Pour les problèmes techniques, nous avons essayé de
dépanner la personne qui avait du mal avec une installation, en lui faisant part de notre
expérience de l’installation et de la configuration du logiciel utilisé.
Pour les problèmes d’ordre logistique, nous avons décidé pendant quelques temps, de
nous retrouver physiquement au même endroit afin d’augmenter notre efficacité et notre
motivation. Ce choix nous a aussi permis de résoudre les problèmes lié à Skype (difficulté
pour expliquer et comprendre les choses, dialoguer plus facilement, etc.).
Enfin, pour la perte d’un des membres, nous avons redéfini les priorités et nous avons
réaffecté les tâches que cette personne devait faire. Cette réaffectation a dépendu de la
productivité des autres membres.
4.5 Travail de chacun
4.5.1 Ken Albertini
Analyse et conception
– étude comparative des logiciels d’évaluation de code.
Développement
– servlet de connexion au serveur FTP.
Documentation
– document sur l’étude comparative des logiciels d’évaluation de code.
25

4.5.2 Yoann Bertrand
Analyse et conception
– étude des fonctionnalités,
– étude de l’IHM,
– étude de l’architecture,
Développement et production
– mise en forme du code du portail (nettoyage, commentaires, corrections mineures),
– servlet de connexion à Jenkins,
– servlet d’authentification au portail,
– code de gestion des utilisateurs FTP (création automatique des répertoires personnels),
– connexion entre Jenkins et le serveur FTP,
– configuration de la machine de tests (installation, configurations système et réseau),
– intégration et tests des différentes parties de code.
Chef de projet
– pilotage du projet (distribution des tâches, dialogue avec l’enseignant),
– mise en forme et validation des documents.
Documentation
– mise en forme du rapport et de la présentation,
– tests utilisateur pour la partie IHM,
– diagramme de GANTT,
– documentation d’installation.
4.5.3 Raphaël Franot
Analyse et conception
– étude comparative des technologies de base de données,
– étude des fonctionnalités,
– étude de l’IHM,
– étude de l’architecture,
Développement et production
– développement du portail,
– servlet de connexion à la base de données,
– servlet de connexion au serveur FTP,
– mise en forme du feedback de Jenkins,
– intégration des requêtes SQL au portail,
– gestion des tests sur Jenkins,
– intégration et tests des différentes parties de code,
26

– création du livrable.
Documentation
– participation au rapport,
– document sur l’étude des bases de données.
4.5.4 Daniel Lludice
Analyse et Conception
– étude comparative des technologies web,
– étude de l’architecture BD,
– étude de l’architecture globale.
Développement et production
– création et modification de la base de données,
– développement des requêtes SQL,
– tests de la BD.
Documentation
– participation au rapport,
– document sur l’étude des technologies web,
– documentation utilisateur.
27

Chapitre 5
Conclusion
Ce chapitre de conclusion est divisé en deux partie. La première permet de lister le
travail effectué, le travail restant à faire et les optimisations possibles. La deuxième partie
permet de donner notre avis sur les différents acquis que ce TER a apporté.
5.1 Travail effectué
Nous avons développé une application qui permet les actions suivantes : (Adm = Administrateur,
En = Enseignant, Et = Étudiant).
– Se connecter au portail en utilisant MySQL. (Adm,En,Et)
– Créer des étudiants. (Adm)
– Créer des enseignants. (Adm)
– Créer des projets. (Adm, En)
– Supprimer des étudiants. (Adm)
– Supprimer des enseignants. (Adm)
– Supprimer des projets. (Adm, En)
– Modifier les informations d’un utilisateur. (Adm)
– Modifier les informations d’un projet. (Adm, En)
– Visualiser les informations d’un utilisateur. (Adm, En, Et)
– Soumettre du code. (Adm, En, Et)
– Soumettre un jeu de test. (Adm, En, Et)
– Voir les résultats d’un projet. (Adm, En, Et)
Pour pouvoir utiliser les fonctionnalités ci-dessus, nous avons effectué un certain nombre
de connexion entre les différentes parties de notre application :
– Connexion Portail - MySQL
– Connexion Portail - Jenkins
– Connexion Portail - Serveur FTP
– Connexion Serveur FTP - Jenkins
– Connexion MySQL - Serveur FTP
28

Nous avons aussi écrit plusieurs documents pour que notre travail soit réutilisable :
– des documents sur les études préliminaires,
– des documentations utilisateurs,
– une documentation d’installation,
– un certain nombres de schémas descriptifs et annexes.
Enfin, nous avons effectué des tests pour valider certaines parties de l’application :
– tests utilisateurs pour l’IHM,
– tests divers avant et pendant le développement.
5.2 Travail restant
Nous n’avons pas effectué la totalité des tâches que nous devions faire. En effet, il
manque un certain nombre de fonctionnalités, comme par exemple :
– La gestion des dates de rendus et des crédits, afin de bloquer le dépôt de code après
échéance.
– L’implémentation de la virtualisation, qui permettrait d’exécuter du code dans des
machines virtuelles, afin d’éviter les problèmes d’exécution d’un code malicieux ou
plein de bugs.
– La corrélation de code, pour pouvoir comparer des projets entre eux afin de s’assurer
que les étudiants n’ont pas utilisé le même code.
– Gérer les groupes d’étudiant, comme des binômes par exemple.
– Créer plusieurs utilisateurs à la fois, afin d’éviter un remplissage de la BD à la main.
Néanmoins, nous avons tout fait pour que ces fonctionnalités soient facilement ajoutées
au portail. En effet, la base de données ainsi que l’architecture globale de l’application
ont été développées dans ce sens 1 . Ainsi, pour les crédits et les dates, il suffirait de coder
une classe qui interroge la BD pour savoir si l’étudiant dispose encore de crédits, et qui
pourrait simplement griser le bouton d’upload le cas échéant.
Pour le remplissage automatique de la base, il faudrait d’implémenter une requête SQL
qui prend un fichier texte en paramètre et remplie automatiquement la base en fonction
du contenu du fichier.
De la même façon, le mécanisme de corrélation de code pourrait être fait grâce à une
Servlet qui comparerait les codes entre eux, grâce à des commandes Unix comme chksum
ou comm.
Enfin, il existe déjà un plugin Jenkins qui met en place la virtualisation, nous n’avons
simplement pas eu le temps de l’utiliser.
1. Notre BD contient les dates, les crédits et les groupes utilisateurs, il manque simplement le code
Java qui permet d’exploiter ces notions.
29

5.3 Optimisation
5.3.1 Simplification de l’installation
Une application ergonomique doit aussi être facile à installer. Pour cela, nous avons
dans un premier temps rédigé une documentation pour aider l’utilisateur à mettre en
place le portail. Malheureusement, l’installation nécessite du temps et des compétences.
Pour éviter ces problèmes, nous avons envisagé de simplifier l’installation avec des scripts.
Pour ce faire, les scripts pourraient :
– Télécharger directement les applications utilisées (Tomcat, MySQL, vsftp, etc.)
grâce à des commandes de type ”wget”.
– Installer automatiquement les applications (en utilisant des commandes idoines
comme ”sh”).
– Configurer automatiquement les applications en copiant directement des fichiers de
configuration aux bons emplacements.
5.3.2 Fonctionnalités
Gestion des groupes
Il pourrait être avantageux de continuer le travail déjà commencé pour permettre à
l’application de gérer des groupes d’étudiants.
Changement de mot de passe obligatoire
Pour cela, il pourrait être envisageable de rajouter dans la table ”Personne” un champ ”is-
FirstConnection” de type booléen. Ce champs (à ”true” par défaut), serait envoyé au portail
qui chargerait alors une fenêtre de modification du mot de passe (déjà implémentée).
Ainsi, l’utilisateur serait obligé de changer son mot de passe à la première connexion.
Gestion dynamique des chemins
Il pourrait être intéressant de faire en sorte que les chemins utilisés par l’application
soit dynamiquement modifiable avec des fichiers de configuration. Une partie de l’IHM
pourrait même servir à modifier ces fichiers, rendant de facto la manipulation encore plus
simple.
Installation sur d’autres systèmes d’exploitation
Pour l’instant, le portail ne fonctionne que sur Linux, à cause de deux choses :
– l’utilisation de chemins de type Unix (exemple : /usr/...)
– l’utilisation de commandes Unix (exemple : chown, locate, etc.)
Comme nous l’avons dit précédemment, le problème des chemins peut être corrigé avec
des fichiers de configuration. En revanche, pour régler le problème des commandes, nous
pourrions utiliser des design patterns.
En effet, les commandes Unix sont relatives à une servlet en particulier, il pourrait être
judicieux d’utiliser les design pattern ”Abstract Factory” et ”Factory Method” pour créer
30

automatiquement des servlets en fonction du système sur lequel l’application est exécutée.
Ainsi, un morceau de code pourrait déterminer le système d’exploitation et créer une servlet
particulière en fonction de ce dernier. Cette solution aurait l’avantage d’être propre
et évolutive et permettrait une meilleure interopérabilité.
5.4 Gain de connaissances techniques
Ce TER a été riche en enseignement d’un point de vue technique, car il a permis
de nous familiariser avec des technologies nouvelles, comme par exemple Jenkins
et l’intégration continue. De plus, nous avons aussi eu la possibilité de mieux comprendre
les technologies vues ou évoquées au cours de cette année universitaire. Par exemple, nous
avons utilisé les cours de M. Richard Grin pour les questions liées à la persistance des
objets. De même, nous avons utilisé GWT, qui était une technologie proposée pour le
projet XML de M. Philippe Poulard. Enfin dans une moindre mesure, nous avons utilisé
les cours de système de M. Fabrice Huet et les cours de réseau de M. Bruno Martin pour
nous aider à installer et configurer la machine de test. Enfin, nous avons mis à profit
les cours d’IHM de Mme Aurore Russo pour essayer de rendre notre application la plus
ergonomique possible, en travaillant dès le début sur l’interface, mais aussi en faisant des
tests sur des utilisateurs en fin de projet.
5.5 Gain de connaissances pratiques
Ce TER nous a aussi permis de mieux appréhender les difficultés inhérentes au travail
en équipe. Nous avons vu qu’il était compliqué de travailler à plusieurs et de prévoir les
problèmes (difficultés techniques, perte d’un membre de l’équipe, etc.). De plus, le fait de
ne pas travailler physiquement au même endroit peut aussi être une source de problèmes.
Néanmoins, nous avons compris qu’une bonne communication entre les personnes était
cruciale pour le bon déroulement du projet.
31

Chapitre 6
Glossaire
A - D
Abstract Factory
Schéma de conception pour la création d’objets regroupés en familles. p.31
ActionScript
Langage de programmation ajoutant de l’interactivité aux objets multimédias (images,
sons, vidéos) en répondant aux actions de l’utilisateur. p.6
AJAX
Asynchronous Javascript and XML. Ensemble de technologies pour la construction d’application
web dynamiques. p.6
Ant
Logiciel d’automatisation de tâches à partir d’un code-source (production de logiciel, de
document/rapports, etc). p.7
API
Application Programming Interface. Interface de programmation fournie par un langage
informatique pour concevoir des programmes dans ce langage. p.7
Bibliothèques
Les bibliothèques informatiques sont des fichiers qui contiennent des fonctionnalités ajoutées
à un langage informatique. p.1
CSV
Comma-separated values. Format informatique de représentation de données. p.7
Design Pattern
Schéma de conception pour la résolution d’un problème donné. p.30
Diagramme de GANTT
Outils graphique pour ordonnancer les tâches d’un projet en fonction du temps et des
32

personnes. p.23
DNS
Domain Name System. Système de Noms de Domaine. Service permettant d’établir une
correspondance entre une adresse IP et un nom de domaine. p.12
Driver JDBC
Pilote logiciel permettant d’établir une connexion entre un programme Java et un système
de gestion de base de données. p.18
F - R
Factory Method
Schéma de conception définissant une interface pour la création d’objet. p.31
FTP
File Transfer Protocol. Protocole de transfert de fichiers permettant, depuis un ordinateur,
de copier des fichiers vers un autre ordinateur du réseau. p.18
GWT
Google Web Toolkit. Ensemble d’outil permettant la création de pages Web dynamiques.
p.6
ICPC
International Collegiate Programming Contest. Un certain type de concours de programmation.
p.11
IDE
Integrated Development Environment. Environnement de développement intégré. Programme
regroupant un ensemble d’outils pour le développement de logiciels. p.8
IHM
Interface Homme-Machine. Moyens mis en œuvre afin qu’un humain puisse communiquer
avec une machine.p.13
HTTP
HyperText Transfer Protocol. Protocole de communication client-serveur. p.17
Maven
Logiciel d’automatisation de production de logiciel à partir de code sources. p.6
MXML
Langage de description, dérivé du XML, pour décrire la présentation des interfaces. p.6
33

MySQL
Un système de gestion de base de données. p.10
RPC
Remote Procedure Call. Protocole réseau permettant de faire des appels de procédures
sur un ordinateur distant. p.10
S - Z
Servlets
Classe Java destinée à créer dynamiquement des données sur un serveur. Elles permettent
aussi de rajouter des fonctionnalités. p.11
SVN
Logiciel de gestion de version de programmes. p.7
Tomcat
Serveur web qui gère des servlets. p.7
URL
Uniform Resource Locator. Chaîne de caractères utilisée pour localiser des ressources. p.17
XML Extensible Markup Language Langage de balisage extensible. Langage informatique
basé sur le principe de balises. Son objectif est de faciliter l’échange automatisé de
contenus complexes. p 9
34

Bibliographie
[1] Google web toolkit. http://code.google.com/intl/fr/webtoolkit/.
[2] Jaxcent. http://www.jaxcent.com/.
[3] Adobe flash. http://www.adobe.com/fr/products/flashplayer/.
[4] Adobe flex. http://www.adobe.com/fr/products/flex/?promoid=BPBOG.
[5] Php. http://www.php.net/.
[6] Microsoft silverlight. http://www.silverlight.net/.
[7] Jenkins ic. http://jenkins-ci.org/.
[8] Continuous integration and build server. http://www.atlassian.com/software/
bamboo/.
[9] Apache continuum. http://continuum.apache.org/.
[10] Mooshak. http://mooshak.dcc.fc.up.pt/.
[11] Domjudge. http://domjudge.sourceforge.net/.
[12] code-cracker, a semi-automated online judge system. http://code.google.com/p/
code-cracker/feeds.
[13] Workspace assembla. http://www.assembla.com/spaces/Portail_KRYD/wiki.
[14] Laurent Debrauwer. Design Patterns pour Java. ENI Ed., 2009.
[15] Smart gwt showcase. http://www.smartclient.com/smartgwt/showcase/
#toolstrip.
[16] Rpc request builder in gwt. http://jagadesh4java.blogspot.com/2009/04/
gwt-rpc-using-request-builder-hi.html.
[17] Le sql de a à z. http://sqlpro.developpez.com/cours/sqlaz/sousrequetes/.
[18] Ci feature matrix. http://confluence.public.thoughtworks.org/display/CC/
CI+Feature+Matrix.
[19] Javadoc. http://download.oracle.com/javase/6/docs/api/.
[20] Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley,
2009.
[21] Richard Grin. Modèle pour la persistance des objets. 2011.
[22] Philippe Poulard. Web - XML. 2011.
[23] Aurore Russo. ergonomie. 2011.
35

Université de Nice - Sophia-Antipolis
Faculté des sciences Valrose
28 avenue valrose, 06103 Nice
Travail d’étude et de recherche
Gestion-évaluation
semi-automatique de projets
ANNEXES
1 er juin 2011
Présenté par :
M. Albertini Ken
M. Bertrand Yoann
M. Franot Raphaël
M. Lludice Daniel
Sous la direction de :
M. Huet Fabrice

Table des annexes
1 Documentation utilisateur I
2 Requêtes SQL III
3 Tests utilisateurs IV
3.1 Tâches à effectuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
3.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
4 Diagramme de GANTT VII

Annexe 1
Documentation utilisateur
Cette annexe montre une petite partie de la documentation utilisateur réalisée. Le
but de cette documentation est de mieux comprendre comment utiliser le portail.
I

Annexe 2
Requêtes SQL
Le schéma suivant montre le mécanisme d’interrogation de la BD via deux requêtes
SQL. Pour faciliter la compréhension, seul les tables et tuples pertinents sont représentés.
La requête 1 permet de récupérer les nom, prénom et email des personnes du groupe
”TER”.
La requête 2 permet de récupérer les projets dont fait parti l’étudiant Dupond.
Figure 2.1 – Mécanisme d’interrogation de la base avec des requêtes SQL
III

Annexe 3
Tests utilisateurs
3.1 Tâches à effectuer
Cette partie décrit les résultats des tâches que nos utilisateurs ont effectué. Ces tâches
exploitent les fonctionnalités de l’application dans un cadre d’utilisation normal. Nos
utilisateurs sont trois ex-étudiants 1 qui ont utilisé l’application pendant 10 minutes avant
de réaliser les tests.
3.2 Résultats
Tâche T1 :
– Créer trois étudiants (nom et informations imposés).
– Modifier le prénom d’un des enseignants (prénom imposé).
Tâche T2 :
– Créer un projet (nom et informations imposés).
– Uploader un jeu de tests pour ce projet (choix du fichier imposé).
Tâche T3 :
– Visualiser les infos d’un des enseignants.(choix libre).
– Soumettre un code (choix du fichier imposé).
Résultats des tâches chronométrées
Ces temps ne prennent pas en compte la connexion au portail.
Noms T1 T2 T3 Total
Nicolas 1min07 49 sec 27 sec 2min23
Maxime 1min12 52 sec 25 sec 2min29
Vincent 1m02 50 sec 22 sec 2min14
1. Ils ne sont plus étudiants depuis moins d’un an.
IV

Résultat de la partie A
Cette partie permet de noter l’application sur quelques critères ergonomiques.
Critères Nicolas (/10) Maxime (/10) Vincent (/10)
Pertinence des menus 8 7 7
Temps de ≪ chargement ≫ 10 10 9
Dispositions des menus 7 8 7
Facilité de navigation 8 8 9
Facilité de compréhension 8 7 6
Moyenne 8.2 8 7.6
Résultat de la partie B
Cette partie permet de voir si les tâches ont été comprises et si elles étaient pertinentes
pour nos utilisateurs.
Critères Nicolas ( /10) Maxime ( /10) Vincent (/10)
Compréhension T1 10 10 9
Compréhension T2 10 10 9
Compréhension T3 9 10 9
Efficacité T1 6 7 7
Efficacité T2 7 8 6
Efficacité T3 8 7 7
Moyenne 8.33 8.66 7.83
Globalement, on peut dire que nos utilisateurs ont trouvé que les tâches étaient pertinentes.
Néanmoins, ils ont trouvé que la tâche 1 (la création de plusieurs étudiants par un
administrateur) était fastidieuse, surtout si l’administrateur devait créer une promotion
entière.
De plus, les testeurs ont trouvé que la tâche 3 (visualiser des informations et soumettre
du code) manquait un peu de substance. Pour pallier ce problème, ils ont proposé de
rajouter une ou deux étapes, comme par exemple modifier son mot de passe ou déposer
un projet fini.
Résultat de la partie C
Les testeurs ont trouvé que les tâches étaient facilement réalisables car les menus étaient
bien ordonnées. En effet, ils ont considérés que le fait d’avoir ajouté des onglets rendait
la navigation plus facile. De plus, ils ont trouvé les temps de chargement excellent et le
design très sobre mais efficace.
Néanmoins, nos utilisateurs ont émis un certain nombre de critiques sur le portail, comme
par exemple :
– Le manque de pertinence pour certains messages de popup (pas assez d’informations).
V

– La nécessité d’appuyer sur le bouton ”Afficher Infos” pour charger les informations.
– Le manque d’informations (format des dates non spécifié) dans le menu de création
d’un projet.
– Le panneau ”descriptif” d’un projet trop petit.
VI

Annexe 4
Diagramme de GANTT
Cette section montre le diagramme de GANTT initialement produit en début de TER.
Figure 4.1 – Diagramme de GANTT initial - partie 1.
VII

Figure 4.2 – Diagramme de GANTT initial - partie 2.
VIII