projet d’informatisation de la gestion des … · étudiants et de leurs absences au cours des...

BERNARDIN Benoît & COLOM Hendrick

Licence Professionnelle Système informatique et logiciel

Responsable du projet : Françoise GREFFIER

PROJET D’INFORMATISATION DE LA GESTION DES ABSENCES

EN STARTER

Année2008/2009

Projet d’informatisation de la gestion en starter BERNARDIN Benoît & COLOM Hendrick

2

SOMMAIRE

I. PRESENTATION DE L’ENVIRONNEMENT STARTER

II. PROBLEME POSE

1. Enoncé 2. Analyse de l’existant 3. Analyse des problèmes 4. Cahier des charges

III. ETUDE PREALABLE – Dossier de choix

IV. CONCEPTION ET REALISATION DE LA SOLUTION 1. Conception – Dossier d’analyse 2. Réalisation – Dossier de développement

V. DESCRIPTION DE LA PHASE DE TRANSITION 1. Formation des utilisateurs 2. Migration des données

VI. CONCLUSION


3

I. PRESENTATION DE L’ENVIRONNEMENT

La gestion administrative des étudiants inscrits en Starter est actuellement gérée par la secrétaire de cette formation. Cette dernière a la responsabilité de permettre le suivi des étudiants et de leurs absences au cours des différents enseignements et semestres. En parallèle, elle s’occupe plus particulièrement des éventuelles convocations liées à un nombre élevé d’absences. Tout cela, fait jusque a la main et prenant quasiment la moitié du temps de travail de la secrétaire.

Au début de chaque cours, les enseignants notent les élèves absents. C’est en fin de semaine que chaque enseignant envoie son compte‐rendu quotidien d’absences qu’il a constaté pour les formations auxquelles il a fait cours. La secrétaire récupère la totalité des comptes‐rendus puis les enregistrent dans des fichiers de gestion au format Excel (essentiellement des tableurs). La gestion administrative des Starter est donc basée sur ces différents tableurs qui permet de repérer les étudiants régulièrement absents ou en difficulté. A savoir que le nombre d’étudiants inscrits en 2008‐2009 est de 238

Le projet qui nous a été confié s’inscrit dans une démarche d’évolution de gestion. En effet, ce système de gestion pose certains problèmes comme la répétition de tâches basiques, qui pourraient être automatisées.


4

II. PROBLEME POSE 1. Enoncé

La gestion des Starter, comme dit précédemment, est donc basée sur des tableurs, créés au fil des années suivant les besoins. Néanmoins, ces derniers, mis à jour quotidiennement, font l’objet de données répétitives, ce qui provoque une accumulation de tâches comme le calcul du nombre d’absences injustifiées d’un étudiant choisi. A titre indicatif, 80% du temps de travail de la secrétaire est dédié à ces tâches rébarbatives.

A cela s’ajoute, le non‐retour éventuel des comptes‐rendus d’absences par les enseignants. En effet, certaines semaines, quelques enseignants oublient involontairement de rendre leur compte‐rendu. Ceci ne facilite donc pas la gestion des absences pour la secrétaire, qui doit rappeler aux enseignants concernés leur oubli.

2. Analyse de l’existant

La gestion administrative est réalisée à l’aide de plusieurs outils logiciels et matériels.

Inventaire matériel

Tous les enseignants et la secrétaire sont équipés d’un ordinateur fonctionnant avec Windows XP Professionnel, et connecté à Internet.

Inventaire logiciel

Aucun logiciel particulier n’est utilisé par les enseignants pour noter les absences constatées. Néanmoins, la secrétaire base sa gestion administrative sur différents tableurs, créés avec Microsoft Excel :

‐ Tableau de gestion des enseignants : Pour chaque semaine et pour chaque enseignant, ce tableau indique si l’enseignant à donner son compte‐rendu. ‐ Tableau d’emploi du temps : Indique pour la formation de Starter concernée, son emploi du temps par semaine ‐ Tableau des absences : Indique les absences des étudiants ‐ Tableau des justifications d’absences : Précise si l’absence a été justifié, et par quel motif.


5

Les acteurs

• La secrétaire qui sera également l’administrateur

• Les enseignants qui rempliront la base de données

3. Analyse des problèmes

La solution en place est très lourde à manipuler et dure à maintenir à jour étant

donné que les fichiers ne sont pas synchroniser entre eux. En effet, les modifications effectuées sur un fichier ne sont pas répercutées immédiatement sur les autres : il n’y a aucune relation entre chaque tableau existant. Par conséquent, les manipulations de gestion sont très répétitives et fastidieuses.

A cela s’ajoute, le problème de non‐retour des absences qui entraine fatalement un manque d’informations.

4. Cahier des charges

Pour résumé, l’objectif principal du projet est :

LE DEVELOPPEMENT D’UNE APPLICATION PERMETTANT LA GESTION DES ABSENCES DES ETUDIANTS VIA UNE INTERFACE WEB

Cette dernière doit répondre aux exigences suivantes :

• permettre de gérer les absences des étudiants de starter en une seule application

• développer une application simple et dynamique


6

III. ETUDE PREALABLE – Choix des outils de développement

Avant toute analyse, une étude des différents outils de développement a été réalisée. En effet, lors de la découverte du projet, l’outil proposé était PHP/MySQL avec l’interface de gestion de base de données PHPMyAdmin.

Néanmoins, Mr Jean‐Michell Caricand a soumis l’idée d’utiliser l’environnement de développement Gantry pour réaliser notre projet.

La décision de développer la future application à l’aide de l’outil Gantry a donc été prise.

Présentation de Gantry

Gantry se base sur une architecture MVC (Modèle‐Vue‐Contrôleur) et s’appuie sur le langage PERL. Gantry utilise des fichier d’extention .bigtop qui permettent de décrire une application en séparant données,affichage et contôle. Il utlise également l’éditeur Tentmaker qui permet lui la création de base de données (table, relation) ainsi que la saise de donnée.

Schéma de l’architecture MVC :

Le schéma ci‐contre représente donc la structure du MVC. On aura dans le cas de notre projet, la base de données sqlite en tant que modèle, les vues seront les pages développées à l’aide de Gantry et les contrôleurs seront générés par bigtop puis les fonctions spéciales seront rajoutées.

Le serveur web sera lancé sur la machine contenant l’application à l’aide d’un fichier spécial contenant le descriptif de l’applicatif


7

IV. CONCEPTION ET REALISATION DE LA SOLUTION

1. Conception‐Dossier d’analyse

Modélisation

Suite à l’étude des différents documents nécessaires à la gestion des Starter, une analyse a été faite s’appuyant sur la méthode d’analyse MERISE/1.

Un modèle conceptuel a donc été réalisé, il est présenté ci‐après :


8

On notera que le modèle a été étudié de façon à permettre à l’application d’évoluer et de permettre de rajouter des fonctions. Ainsi lors de nos entretiens plusieurs points ont été définis comme par exemple la gestion du tutorat.

La base de données contiendra donc l’ensemble des informations nécessaires sur les étudiants du starter ainsi que leurs groupes de TD et TP. Les enseignants sont également enregistrés dans la base et se verront attribuer des cours (ici enseignement) et pourront éventuellement être responsable d’une unité. De plus, la gestion des emplois du temps est permise grâce à ce modèle via les tables horaire et type_cours.

Environnement de développement

Après avoir déterminé les outils de conception, une réflexion a été nécessaire sur l’architecture logicielle et matérielle utilisée pendant, puis après, le développent de l’application. Le schéma ci‐après présente les logiciels utilisés ainsi que la structure matérielle :

Client Réseau Serveur Système

d'exploitation Windows XP, vista Linux Debian

Logiciels utilisés NoMachine Gantry Sqlite

PostGres

Remarques Connexion VPN


9

Le serveur utilisé utilise le système d’exploitation Debian sur lequel est installé l’ensemble de l’architecture nécessaire au développement à savoir :

• Gantry : le logiciel qui permettra de générer l’application ainsi que la base de données basé sur l’architecture MVC ainsi que PERL. Site de référence : http://usegantry.org/

• Sqlite : Système de Gestion de Base de Données Site de référence : http://www.sqlite.org/

• PostGres : Système de Gestion de Base de Données Site de référence : http://www.postgresql.org/

• NoMachine : logiciel permettant d’accéder à un bureau virtuel a distance Site de référence : http://www.nomachine.com/

On notera que l’ensemble des logiciels utilisés sont issue du monde libre. De plus, le système d’exploitation utilisé coté client n’est pas d’une importance capitale sachant que le logiciel NoMachine est multi‐plate‐forme.

On utilise une connexion VPN (Virtual Private Network) pour se connecter au serveur et donc accéder au réseau de l’unversité.

2. Réalisation – Dossier de développement

La souplesse de l’architecture de Gantry permet un développement simplifié. Ainsi, dans un premier temps, via la console Linux on créera un fichier d’extension .bigtop qui contiendra l’ensemble des commandes pour générer la base de données sous une forme spéciale qui permettra d’utiliser plusieurs SGBD (tel que PostGres ou sqlite qui seront utilisé pendant le développement du projet). Seront également générer des droits sur le modèle ainsi que des contrôleurs.

Nous allons expliquer par la suite les quelques commandes nécessaires au démarrage

du développement.

A noter que la majorité des commandes s’exécute dans la console Unix.


10

Création des dossiers et des fichiers nécessaires

Tout d’abord la commande Bigtop ‐‐new App application permet de créer l’ensemble des fichiers nécessaire à l’application. Cette commande créera un dossier App contenant l’ensemble des fichiers nécessaires. Parmi ces fichiers on notera la présence des fichiers suivant qui seront utilisés par la suite :

• App.server : fichier qui permet de lancer le serveur web pour lancer l’application

• App.bigtop : fichier qui contiendra tout le descriptif de l’application à savoir le modèle et les contrôleurs.

• App.cgi : fichier qui contient le script CGI de l’application

Deux dossiers sont également créés :

• html : dossier qui contiendra les fichiers temporaires ainsi que les fichiers web, à savoir les .css et .html qui seront dans ce cas la composante Vue du modèle MVC.

Mise en place de la base de données

Une fois la structure en place, la commande sqlite app.db < docs/schema.sqlite génère un fichier dans le répertoire docs nommé schema.sqlite qui permettra l’écriture des tables dans le SGBD sqlite.

Enfin dernière commande pour pouvoir implanter la base de données : ./app.server [port] qui va lancer un serveur sur la machine sur le port rentré en paramètre. Ce serveur sera accessible en demandant l’URL localhost :port au navigateur web. C’est un serveur web temporaire dont le graphisme est défini par Gantry et qui peut être modifié.

Enfin la commande tentmaker –p port docs/App.bigtop qui va lancer tentmaker sur le port donné et qui permettra de créer les tables nécessaires et de gérer la base de données.

Cependant, il est préférable de réaliser les relations entre les tables en ligne de commande car bigtop va encore jouer un rôle important en modifiant les contrôleurs et en insérant les clés étrangères aux bons endroits.

Cette commande est la suivante : tentmaker –a docs/App.bigtop ‘etudiant‐>groupetp’. Ces modifications seront enregistrées dans le fichier App.bigtop qu’il faudra bien évidement réutilisé pour lancer le serveur avec les données mise à jour.


11

Développement des contrôleurs

Une fois la base en place plusieurs points techniques restent a mètrent en place. Parmi ces points : l’authentification. Et encore une fois, Gantry va permettre un développement simplifié et aisé car grâce a des plugins et a l’intégration de quelque lignes de code, l’authentification peut être réalisée.

Les autorisations vont pouvoir être mise en place grâce aux contrôleurs. Par exemple seul la secrétaire a tout les droits sur les tables, les enseignants ne pourront qu’ajouter des absences et éventuellement les modifier.

Ces contraintes seront ajoutées au contrôleur de la table assister et permettront une meilleure cohérence des données dans la base.

Mise en place des vues

L’apparence de l’application, elle aussi, va pouvoir bénéficier de la souplesse de Gantry. Ainsi, on modifiera l’apparence générale puis on ajoutera les vues sous forme de fichier html et les redirections se feront dans le fichier descriptif de l’application.


12

V. DESCRIPTION DE LA PHASE DE TRANSITION

1. Formation des utilisateurs

Deux types d’utilisateurs seront amenés à interagir avec l’application :

• La secrétaire qui sera la principale utilisatrice et administratrice aura besoin d’une formation spécifique afin de naviguer et de gérer les données.

• Les enseignants seront les utilisateurs secondaires et afin d’assurer une utilisation correcte une fiche pourra être rédigée afin de permettre une prise en main plus aisée.

2. Migration des données

Suite aux différents entretiens avec Mr Caricand, il semble que les données seront importées d’une base déjà existante au sein de l’université, ce qui permettrait de migrer la plupart des informations en évitant un travail fastidieux de saisie de données à la secrétaire.

3. Phase de transition

L’application devant être opérationnelle pour la rentrée prochaine à savoir septembre 2009, la transition se fera à ce moment précis. La secrétaire du bureau Stater continuera de travailler avec ses fichiers Excel pour cette fin d’année.


13

VI. CONCLUSION

Avancement du projet

A l’heure actuelle, le projet n’est pas terminé. En effet, l’architecture utilisée ainsi que le langage ont été un frein au déroulement du projet. Cependant, la base de données ainsi que les contrôleurs de l’application sont en place et via Tentmaker il est possible de réaliser l’insertion, la modification et la suppression de données. De plus afin d’assurer la gestion des absences tout en continuant le développent, le même projet a été développé dans le langage php.

Modifications possibles

La base de données ayant été développée dans le but de pouvoir étendre l’application, certains ajouts peuvent être permis tel que la gestion des emplois du temps, des examens ou encore le tutorat tout cela bien sûr pour le semestre starter et afin de simplifier le travail de la secrétaire.

Apport personnel

Ce projet a été l’occasion de découvrir une nouvelle façon de programmer grâce au logiciel Gantry, à son architecture MVC et son langage PERL. Ce fut également l’occasion de travailler sur un projet et de développer une application de la partie d’analyse jusqu’à son achèvement. De plus, le fait de travailler en collaboration avec monsieur Carricant, nous a permis d’être plus proche du monde du travail que des études et d’avoir une œil plus critique sur le projet et son avancement.


14

REMERCIEMENTS

Nous tenions à remercier Monsieur Jean‐Michell Caricand, ingénieur au LIFC, qui nous a guidé et aidé durant toute la réalisation du projet, ainsi que Madame Françoise Greffier qui a supervisé notre projet ainsi qu’a la secrétaire du service informatique qui nous renseigné sur sa méthode de travail ainsi que sur ses attentes.


15

BIBLIOGRAPHIE

Sites Web :

• Gantry : http://usegantry.org/

• Sqlite : http://www.sqlite.org/

• PostGres : http://www.postgresql.org/

• NoMachine : http://www.nomachine.com/

Documentation utilisateur :

• Building Web Applications with Gantry And Bigtop Version 1.1, Philip Crow


16

Résumé:

Ce rapport traite du projet de Licence professionnelle Système Informatiques et Logiciels visant à développer une application de gestion des absences des étudiants du semestre Starter de l’université de Franche‐Comté. Cette application utilise l’environnement de développement Gantry ainsi qu’une base de données sqlite.

This report processes as the project of professional License Système Informatiques et Logiciels to develop an application of management of the absences of the students of the Starter of the university of Franche‐Comté. This application uses the environment of development Gantry as well as a sqlite database.

projet d’informatisation de la gestion des … · étudiants et de leurs absences au cours des...

Documents