Déroulement de la soutenance :

GESTION DES POURSUITES D’ETUDES PPD N°11

31 Mars 2004

PPD N° 11

Vincent de Lemeny Makedone

Moustafa Hassanaly

Ronan Henrio

Leila Kadji

Yani Penet

Antoine Walter

Professeurs encadrant le PPD

Monsieur Jérôme FESSYMadame Evelyne Flandrin

remerciements :

Nous tenons particulièrement à remercier monsieur Fessy pour nous avoir suivi tout au long du projet et pour nous avoir fournis tous les conseils, outils et méthodes nécessaires.

Nous tenons à remercier madame Flandrin, madame Ravi et monsieur Alban pour nous avoir fournis tous les éléments essentiels au contenu du site.

Nous tenons également à remercier monsieur Guillaume, madame Dirani, madame Leclerc et madame Damiral pour nous avoir aidé de près ou de loin à la réalisation de ce projet.

SOMMAIRE

7INTRODUCTION

Présentation des poursuites d’études7

Description du projet7

Intérêt du sujet8

Répartition des tâches8

Plan du rapport8

LES ENTRETIENS10

Entretien avec la responsable des poursuites d’études du département informatique10

Entretien avec la responsable de gestion administrative des poursuites d’études du Département informatique11

Entretien de mise au point des besoins et des fonctionnalités nécessaires12

CAHIER DES CHARGES FONCTIONNEL 13

Présentation de la gestion actuelle des poursuites d’études13

Description de l’existant13

Les acteurs13

Périmètre et objectifs du projet13

Contraintes14

Expression des besoins fonctionnels14

Découpage en lots15

Recette, garantie, maintenance15

Cadre juridique et financier16

Conditions de remise et période d’exécution des prestations16

ANALYSE17

Analyse globale17

Diagramme des cas d’utilisation17

Diagramme de classe18

Diagrammes de séquence19

Présentation d’une solution et évolution de la demande23

Evolution de la solution (prise en compte des restrictions utilisateur)24

Diagramme des cas d’utilisation24

Diagramme de classes25

Diagrammes de séquence26

Fiches descriptives des cas d’utilisations principaux28

ORGANISATION DU SITE33

Création de la base de donnée mysql 33

Création de la structure de la base de donnée33

Importation de la BD existante33

Données importantes et jeu d’essai33

Problématique et choix techniques 34

Une application multi-utilisateurs34

Une application ouverte34

Une application sécurisée35

Organisation générale du site 36

La gestion des utilisateurs39

L’identification39

Les droits d’accès40

Les optimisations 41

Les requêtes41

Les accès à la base de données42

LOT ETUDIANT43

Interface « consulter voeux » 43

LOT ADMINISTRATIF44

Réalisation de la fonctionnalité du tableau récapitulatif (ainsi que filtres et tris) 44

Réalisation des fonctionnalités de gestion des établissements, gestion des filières et de gestion des enseignements 46

Gestion des documents 47

Les importations48

Importation des Etudiants48

Importation des notes des étudiants48

Gestion de l’opération au niveau du langage :49

Les paramètres50

Gestion de la page au niveau organisationnel50

Affichage de la décision du pré jury :51

Permettre la saisie des vœux dans une période donnée51

Nombre maximum de vœux par université/licence/école52

Réalisation de la fonctionnalité d’impression des documents officiels 53

Réalisation de la fonctionnalité de saisie des avis du pré jury 54

LOT INFORMATIF56

La recherche d’informations56

Les voies de poursuites d’études56

Questions supplémentaires57

Implémentation de la partie informative sur le site 57

Les voies de poursuites d’études58

La Foire aux Questions62

Gestion de la faq 64

CONCLUSION 66

Bilan sur le projet66

Principaux problèmes rencontrés67

Bilan humain67

Réflexion sur la relation entre théorie et pratique67

Perspective d’évolution de l’application68

ANNEXES69

Guide de démarrage 69

Carnet de bord72

Aide en ligne 76

diagramme de gantt82

Ppd management of the studies pursuits83

GLOSSAIRE86

INTRODUCTION[de Lemeny] [Kadji] [Penet]

présentation des poursuites d’études

Bien que la formation en IUT ne soit pas destinée à poursuivre des études, certains élèves souhaitent valider un enseignement de niveau supérieur.

Toutefois, la majorité des élèves en DUT Informatique envisage une poursuite d’études, c’est pourquoi il est important de mettre en place un processus de gestion des poursuites d’études.

En effet, les étudiants souhaitent de plus ne plus continuer leurs études afin d’élargir leurs connaissances, se réorienter, se spécialiser ou accéder à des postes à plus grandes responsabilités.

La démarche à suivre pour pouvoir prétendre à des poursuites d’études consiste à formuler des vœux auprès des établissements concernés mais également auprès de la direction de l’IUT. Celle-ci formule alors un avis en fonction des capacités et des résultats de l’étudiant.

En général, les candidatures dans les établissements s’accompagnent de documents à remplir par le candidat et par l’IUT ainsi que d’une date butoir de remise du dossier.

Après sélection du dossier, les étudiants peuvent éventuellement être convoqués à un entretien afin de présenter leurs motivations à vouloir poursuivre leurs études et plus particulièrement dans la filière souhaitée.

description du projet

Le projet consiste à améliorer la gestion des poursuites d’études pour l’administration du département Informatique de l’IUT. Il a pour but d’informer les étudiants sur les poursuites d’études existantes et de leur permettre de formuler leurs vœux aussi bien au niveau universitaire qu’au niveau des écoles d’ingénieur. Ainsi il permettra à l’administration de prendre en compte ces demandes et de les traiter via le pré jury.

Nous avons donc décidé de réaliser un site Internet en PHP s’appuyant sur une base de données MySQL. Le site comprendra deux grandes parties : la première sera réservée aux étudiants (saisie des vœux ou modification des vœux existants, consultation de leurs voeux, indication du nombre de documents demandés pour chaque vœu avec la date butoir…)

La seconde sera quant à elle réservée à l’administration et aux enseignants du département, et leur permettra : la visualisation globale des vœux via un tableau récapitulatif avec possibilité de tri, la visualisation des vœux étudiant par étudiant, la validation des établissements non répertoriés dans la base ainsi que la saisie des avis du pré jury.

De plus, le site comprendra une partie informative afin de répondre aux questions des étudiants sur les poursuites d’études possibles (contenu des formations, statistiques, liens vers des établissements, coordonnées…).

Il nous est demandé un travail soigné aussi bien du point de vue technique (rapidité d’exécution, stabilité, absence de bugs…), que du point de vue ergonomique (agréable à la vue, convivial, intuitif…) puisqu’il s’agit d’un produit répondant à des besoins réels et qui donnera lieu à une réelle utilisation.

intérêt du sujet

Nous avons choisi de travailler sur le sujet concernant la gestion des poursuites d’études pour deux raisons principales :

- Les quatre étudiants en option CDL voulaient approfondir leurs connaissances en matière de programmation Internet. En effet, le PHP étant un des langages les plus utilisés, il nous semblait intéressant de mettre en pratique nos acquis sur un projet concret.

- Pour tous, c’était l’occasion de développer un projet répondant à des besoins réels et immédiatement utilisable. Le fait que l’application développée soit demandée par l’administration de l’IUT, impliquait que nous nous mettions à la place d’une entreprise de services informatique (SSII). Cela impliquait de respecter toutes sortes de contraintes, c’est-à-dire la fiabilité de l’application, les délais de conception ou bien encore le respect des exigences de la maîtrise d’ouvrage.

Cela nous permettait également de nous informer sur les poursuites d’études et de la procédure d’accès à celles-ci.

répartition des tâches

Dans notre équipe composée de 6 développeurs, les tâches ont été réparties de la façon suivante :

Toute l’équipe a participé à l’analyse du projet et au listage des besoins, basée sur le cahier des charges et comportant notamment toute la modélisation UML.

· Le cahier des charges a été réalisé par : Kadji, Hassanaly, Penet, de Lemeny

· La base de données a été créée par : Henrio, de Lemeny.

· Le jeu d’essai a été réalisé par : Henrio, de Lemeny, Hassanaly, Penet

· les maquettes ont été réalisées par : Walter, de Lemeny

· Le site web programmé en PHP 

· le lot Etudiant a été réalisé par : de Lemeny, Hassanaly, Henrio, Walter

· le lot Administration a été réalisé par : Walter, Penet, Hassanaly

· la partie informative a été réalisée par : Hassanaly

plan du rapport

Le rapport sera organisé selon la répartition des tâches précédemment évoquées.

Dans un premier temps, nous exposerons un résumé des différents entretiens que nous avons obtenus et des besoins qu’ils nous ont permis de recenser. Nous en avons déduit le cahier des charges fonctionnel qui fera donc l’objet de la seconde partie de notre dossier.

Ensuite nous exposerons l’analyse complète que nous avons réalisée, les restrictions qui ont été nécessaires et les choix techniques effectués. Cette partie s’avère conséquente puisque nous avons du l’adapter aux restrictions, nous présenterons donc l’ensemble des deux analyses.

Puis nous décrirons la phase de réalisation de la base de données, du choix du système de gestion de base de données et de l’organisation de la structure du site en classes PHP.

Ensuite nous décrirons la phase de développement du site web. Nous exposerons les fonctionnalités réalisées en expliquant les choix techniques, le choix du langage de programmation et les problèmes techniques rencontrés. Ces explications porteront sur les différents lots.

Enfin, nous décrirons la phase de test en comparant les objectifs et les résultats obtenus.

Pour conclure, nous dresserons un bilan du projet, nous mènerons une réflexion sur le travail en équipe, et nous proposerons des améliorations qui pourraient être éventuellement apportées au produit réalisé.

LES ENTRETIENS[Penet]

Entretien avec la responsable des poursuites d’études du département informatique

Compte rendu de la réunion du lundi 07 mars 2005

avec Mme Flandrin (responsable des poursuites d’études et tutrice de PPD)

et Mme Dirani (directrice des études des 2ème années)

Objectif de la réunion :

Obtenir des informations sur le déroulement du pré jury et sur le processus de gestion des poursuites d’études.

Obtenir un énoncé clair des besoins de Madame Flandrin et de Madame Dirani.

Résumé des besoins exprimés :

Le besoin principal est de permettre aux étudiants de saisir leurs vœux de poursuites d’études aussi bien au niveau universitaire, qu’au niveau des écoles d’ingénieurs ou des licences professionnelles.

Cette fonctionnalité permettrait d’éviter à madame Ravi (chargée administrative des poursuites d’études) d’avoir à saisir les vœux de chaque étudiant.

Madame Flandrin a principalement insisté sur la possibilité pour le corps enseignant de consulter les vœux des étudiants et de visualiser la liste des documents à traiter concernant chaque demande de poursuite d’études, ainsi que leurs dates butoirs de remise.

Le besoin de madame Flandrin consiste également à fournir aux étudiants un suivi de leurs demandes en leur précisant l’avancement du traitement de leurs documents (en attente, remplis, envoyés…).

Madame Dirani a, quant à elle, exprimé le désir que le produit permette aux étudiants de se renseigner sur les poursuites d’études et de répondre aux questions les plus fréquemment posées.

entretien avec la responsable de gestion administrative des poursuites d’études du département informatique

Compte rendu de la réunion du mercredi 09 mars 2005

avec Mme Ravi (responsable de gestion administrative des poursuites d’études)

Objectif de la réunion :

Obtenir des informations sur le processus de gestion des poursuites d’études au niveau administratif et sur les documents réalisés par madame Ravi.

Obtenir un énoncé clair de ses besoins.

Résumé des besoins exprimés :

Madame Ravi nous a confirmé que son besoin principal est de permettre aux étudiants de formuler leurs vœux (universitaires, écoles, licence professionnelles) via une interface automatisée lui permettant d’accéder directement à ces demandes.

L’accès à ces demandes lui permettrait de réaliser les documents nécessaires au pré jury.

Un des besoins essentiels de madame Ravi consiste à réaliser un tableau récapitulatif des demandes permettant au pré jury de visualiser l’intégralité des demandes. Ce tableau consistera à trier les demandes sur 4 types de vœux :

· MIAGE/GMI

· Licence universitaire

· Ecole

· Licence professionnelle

La possibilité de trier (voir filtrer) ce tableau sur d’autres critères comme les notes ou bien les groupes par exemple a été évoquée.

Madame Ravi nous a également expliqué l’utilisation qu’elle faisait du produit existant et nous en a fait une démonstration. On a donc pu en déduire par exemple qu’il fallait permettre à l’étudiant de formuler un vœu pour une université et filière (ou école, licence professionnelle) n’était pas répertorié dans la base actuelle.

Par contre lors de cet entretien, madame Ravi nous a précisé que le processus de suivi des documents n’était pas réalisable de part le temps que cela lui prendrait. Cet entretien nous a donc obligé à réévaluer notre analyse en fonction de ces restrictions.

entretien de mise au point des besoins et des fonctionnalités nécessaires

Compte rendu de la réunion du mardi 15 mars 2005

avec Mme Ravi (responsable de gestion administrative des poursuites d’études)

Mme Flandrin (responsable des poursuites d’études et tutrice de PPD)

Mr Fessy (spécialiste en base de données et tuteur de PPD)

Objectif de la réunion :

Clarifier les fonctionnalités nécessaires du produit et le rôle de chacun des intervenants dans le processus de suivi des documents.

Résumé des besoins exprimés et des fonctionnalités demandées:

Madame Flandrin a insisté sur le besoin d’un suivi des documents permettant aux étudiants d’être plus informés sur l’avancement de leurs dossiers.

Au contraire madame Ravi nous a confirmé qu’elle n’était pas en mesure d’assurer un suivi complet de chacun des documents.

L’intérêt de l’entretien a donc été de trouver une solution permettant d’assurer un minimum de suivi des documents.

La solution proposée consiste à permettre aux étudiants de saisir le nombre de documents dont ils ont besoin pour un vœu et d’y associer une date butoir. Cette solution permettra donc à madame Flandrin de visualiser les vœux et les dossiers à traiter prioritairement.

En accord avec les différents participants, l’analyse du projet portera sur la fonctionnalité complète de suivi des documents demandée par madame Flandrin. Cependant le développement sera limité à la possibilité expliquée précédemment (nombre de documents et date butoir).

Les autres fonctionnalités comme celles de saisie des vœux par les étudiants ou du tableau récapitulatif des vœux n’ont pas été remises en cause.

CAHIER DES CHARGES FONCTIONNEL[de Lemeny] [Hassanaly] [Kadji] [Penet]

Présentation de la gestion actuelle des poursuites d’études

L’organisation de la gestion des poursuites d’études actuelle n’est pas totalement informatisée.

Les étudiants remplissent des fiches où ils indiquent les 5 vœux universitaires au maximum (et les filières associées) ; ils y indiquent également les écoles souhaitées.

Ces fiches sont ensuite remises à la secrétaire (Mme Ravi) qui ressaisit les vœux de chaque étudiant sur son logiciel actuel de gestion des poursuites d’études (voir description ci-dessous). Puis celle-ci (Mme Ravi) regroupe les vœux des étudiants sur une feuille Excel où elle rajoute les notes annuelles de chaque étudiant (Extraites manuellement de la base de données des notes).

Cette feuille Excel est ensuite imprimée pour le pré jury qui l’utilise et la remplit en y inscrivant l’avis formulé. Ce document est alors remis à Mme Ravi (support papier) qui ressaisie les informations sur sa feuille Excel et sur le produit de gestion (sur le logiciel Access).

Elle imprime enfin les avis favorables, les remet à la direction qui les approuve.

Description de l’existant

Une base de données Access avec une interface lui permettant de :

· Enregistrer les vœux de chaque étudiant

· Enregistrer les avis correspondants.

· Enregistrer des universités et des filières dans la base de données.

· Imprimer : Avis favorables des étudiants, par filière, par université, par étudiant etc…

les acteurs

Acteur principal : La secrétaire, Mme Ravi, responsable de la gestion administrative des poursuites d’études

Responsable des poursuites d’études : Mme Flandrin et membre du pré jury

périmètre et objectifs du projet

L’objectif du projet est de remplacer le système informatique actuel de manière à l’informatiser intégralement. Il permettra à la secrétaire d’éviter les multiples saisies et de mettre à sa disposition une nouvelle interface plus conviviale avec plus de fonctionnalités, permettant également de générer un tableau équivalant à celui réalisé pour l’instant sur Excel. Il a donc aussi pour but de permettre aux étudiants de saisir d’eux-mêmes leurs vœux. Un autre besoin exprimé par madame Flandrin est celui de pouvoir connaître le nombre de documents nécessaires à un étudiant pour un vœu et la date butoir de remise de ces documents.

Le projet a également pour objectif de permettre une meilleure communication entre les différents acteurs intervenant dans la gestion des poursuites d’études tout en améliorant les services offerts (interface de saisies, statistiques, point d’information pour les étudiants…).

contraintes

Le projet devra être réalisé dans la durée fixée des projets pluridisciplinaires, c'est-à-dire quatre semaines au maximum.

Différents types de droits devront être définis pour l’accès au site :

Un accès étudiant :

Permettant aux étudiants d’accéder à l’interface de saisie et la consultation de leurs vœux.

Un accès administration :

Permettant aux membres de l’administration et aux enseignants de visualiser l’ensemble des vœux, d’y formuler un avis et de régler certains paramètres favorisant l’évolution et l’enrichissement du site (nombre de vœux universitaires autorisés, période de saisie des vœux, affichage des avis ou non aux étudiants, ajout d’université ou d’écoles...)

Un accès visiteur

Permettant de visualiser diverses informations concernant les différentes poursuites d’études, et des réponses aux questions les plus fréquemment posées.

Un processus d’identification permettra donc à chacun des acteurs d’accéder aux parties précédemment citées.

expression des besoins fonctionnels

Nous allons exprimer les besoins fonctionnels en fonction des différents acteurs :

Administrateurs (jury et secrétaire) :

· Création d’une base annexe actualisée par les données de la base actuelle de gestion de la scolarité. 

· Validation des établissements non répertoriés.

· Actualisation des données.

· Consultation des vœux saisis par l’étudiant.

· Affichage du nombre de dossiers à traiter (nombre de documents et date butoir).

· Prévision d’une période de saisie au bout de laquelle il ne sera plus possible de saisir des vœux.

· Possibilités d’impression d’un tableau récapitulatif de recensement des demandes des étudiants pour le pré jury.

· Saisie des avis du pré jury pour chaque étudiant.

Etudiants :

· Saisie des vœux de poursuites d’études via un menu déroulant.

· Possibilités de rentrer un établissement non répertoriés dans la liste existante.

· Possibilités du suivi des vœux.

· Consultation, modification, voir suppression des vœux.

· Une partie informative sur les poursuites d’études existantes.

découpage en lots

Nous avons découpé notre travail en plusieurs parties :

· Analyse

· Création de la base de données

· Création des jeux d’essais

· Conception des maquettes des fenêtres

· Conception de la partie étudiant du site

· Conception de la partie administrateur du site

· Conception de la partie informative

· Recherche des améliorations éventuelles

recette, garantie, maintenance

Tous les tests nécessaires devront être effectués pour assurer le bon fonctionnement et la fiabilité de l’application.

Les opérations de maintenances futures seront assurées par l’équipe informatique de l’IUT.

cadre juridique et financier

Il faudra détailler les fonctionnalités de l’application proposée.

Seront précisés le matériel et les logiciels utilisés pour la conception du produit.

Il est rappelé qu’il est obligatoire d’assurer la gratuité des prestations (la réalisation sera compensée par une note finale).

conditions de remise et période d’exécution des prestations

Préciser les démarches, choix et priorités concernant la réalisation du projet.

Un journal de bord devra être établi.

Le projet devra être réalisée pour le 28 mars 2005.

Une soutenance orale du projet sera réalisée dans la semaine du 28 mars.

ANALYSE[Kadji]

analyse globale

diagramme des cas d’utilisation

Diagramme de classe

· L’attribut « confirmer » est utilisé dans le cas où l’étudiant ajoute une université ou une filière non répertoriée.

· « confirmer = oui » quand la secrétaire a validé la filière ou l’université.

diagrammes de séquence

Se connecter

Ajouter documents

Saisie d’un voeu

Modifier voeu

Saisie des avis pré jury

Supprimer voeu

On supprime la filière et l’université liées au vœu dans le cas où elles ont été ajouté et n’ont pas été validés par la secrétaire

Consultation voeux

Visualisation des vœux (avec tri)

Mise a jour de l’avancement

présentation d’une solution et évolution de la demande

Nous sommes parti sur l’analyse des besoins de Mme Flandrin. C’est-à-dire un suivi pas à pas des poursuites d’études :

· Saisie des vœux par l’étudiant

· Saisie des documents fournis à l’administration avec date butoir

· Validation par l’administration des documents remplis

· Possibilité par l’étudiant et l’administration de la visualisation de l’avancement du dossier des vœux de l’élève

Nous avons développé une solution d’après les besoins énoncés, que nous avons présenté à la secrétaire (personne gérant la poursuite d’étude au niveau administratif). Voici un exemple de maquette que nous avions réalisé pour vérifier si notre solution apportait une réponse aux besoins exprimés.

Apres discussion avec la secrétaire, nous avons constaté que ses propres besoins dissonaient avec ceux de la présidente du pré jury, comme expliqué dans les comptes rendu d’entretien.

En effet la demande de suivi des documents pour chaque étudiant proposé par la présidente du jury, ne peut être réalisable selon la secrétaire.

Nous sommes par conséquent reparti sur une analyse parallèle à la première qui répondait à la fois aux besoins des deux intervenants.

évolution de la solution (prise en compte des restrictions utilisateur)

Diagramme des cas d’utilisation

diagramme de classes

· L’attribut « confirmer » est utilisé dans le cas où l’étudiant ajoute une université ou une filière non répertoriée.

· « confirmer = oui » quand la secrétaire a validé la filière, l’université, l’école ou la licence professionnelle.

· L’attribut « miage_gmi » dans la table filière permet d’éditer le tableau récapitulatif en séparant les filières de type MIAGE ou GMI des autres filières classiques en université.

diagrammes de séquence

i. Saisi d’un voeu

ii. Supprimer voeu

· On supprime la filière et l’université liées au vœu dans le cas où elles ont été ajouté et n’ont pas été validées par la secrétaire

fiches descriptives des cas d’utilisations principaux

· Se connecter

Description : Ce cas d’utilisation permet à l’utilisateur de se connecter et d’accéder un menu

qui propose diverses fonctionnalités.

Acteurs : Utilisateurs

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendus : Aucun

Hypothèses : Aucune

Pré conditions : L’utilisateur doit au préalable être enregistré dans la base de données.

Scénario : Ce cas d’utilisation est lancé lors de la saisie de l’identifiant et mot de passe de

l’utilisateur. L’utilisateur peut être connecté en tant qu’étudiant ou administrateur

suivant son identification.

Il peut y avoir une erreur d’authentification (login et/ou mot de passe incorrect).

Dans le cas contraire, l’utilisateur accède un menu qui propose diverses

fonctionnalités selon qu’il soit un étudiant ou un administrateur (secrétaire,

enseignants, jury).

Flux sortant : Utilisateur identifié. Page personnalisée.

· Saisie d’un vœu universitaire

Description : Ce cas d’utilisation permet à l’étudiant d’enregistrer un vœu universitaire.

Acteurs : Etudiant

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendu : Demande d’ajout d’une université ou filière non répertoriée

Ajouter documents

Hypothèse : L’étudiant ne peut pas saisir plus de 5 vœux universitaires

Pré conditions : L’étudiant doit au préalable être identifié.

Scénario : Ce cas d’utilisation est lancé lorsque l’étudiant veut saisir des vœux universitaires.

Il doit préciser l’université et la filière.

Il a également la possibilité de saisir une université ou filière non répertoriée qui

sera validée en suite par la secrétaire.

Il peut aussi préciser le nombre de documents désirés et indiquer la date butoir.

Flux Sortant : Vœu enregistré.

· Modifier un vœu universitaire

Description : Ce cas d’utilisation permet à un étudiant de modifier un vœu universitaire déjà enregistré.

Acteurs : Etudiant

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendus : Ajouter documents

Supprimer documents

Hypothèses : On suppose que si l’étudiant désire modifier l’université ou la filière, cela

consiste à supprimer le vœu et à en effectuer un autre.

Pré conditions : L’étudiant doit au préalable s’être identifié et donc exister dans la base. Au

moins un vœu universitaire doit être déjà enregistré.

Scénario : Ce cas d’utilisation est lancé sur la demande de l’étudiant après avoir enregistré un

vœu. L’étudiant aura la possibilité de modifier le nombre de documents désirés et/ou changer la date butoir.

Flux sortant : Mise à jour des informations dans la base de données.

· Supprimer un vœu universitaire

Description : Ce cas d’utilisation permet à un étudiant de supprimer un vœu universitaire

déjà enregistré.

Acteurs : Etudiant

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendus : Aucun

Hypothèses : On supprime l’université et la filière dans le cas où elles n’étaient pas

répertoriées et n’ont pas été encore validé par la secrétaire.

Pré conditions : L’étudiant doit au préalable être connecté.

Scénario : Ce cas d’utilisation est lancé par l’étudiant dans le cas où il souhaiterait supprimer

un vœu déjà enregistré.

Flux sortant : Vœu supprimé, mise à jour de la base de donnée.

· Consultation des vœux universitaires

Description : Ce cas d’utilisation permet à l’étudiant de consulter les vœux universitaires déjà

effectués.

Acteurs : Etudiant

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendu : Consulter les documents

Pré conditions : L’étudiant doit au préalable s’être connecté.

Hypothèses : Aucune

Scénario : Ce cas d’utilisation est lancé sur la demande de l’étudiant après s’être identifié.

Il a la possibilité de consulter les vœux universitaires déjà effectués ainsi que les

documents demandés et la date butoir précisée.

Flux Sortant : Aucun.

· Visualisation des vœux avec tri

Description : Ce cas d’utilisation permet à l’administration de visualiser les vœux des

étudiant suivant un critère de tri.

Acteurs : Administrateur (secrétaire, enseignants, jury)

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendus : Editer

Hypothèses : Aucune

Pré conditions : L’administrateur doit au préalable s’être identifié et doit posséder les droits

d’accès.

Scénario : Ce cas d’utilisation est lancé à la demande de l’administrateur, il a la possibilité de

visualiser les vœux des étudiants suivant un critère de tri sélectionné au préalable. Ainsi il aura la possibilité de visualiser les vœux pour un étudiant par exemple…

Un tableau récapitulatif lui sera proposé et s’il le désire il aura également la

possibilité d’imprimer ce tableau.

Flux sortant : Tableau récapitulatif des vœux.

· Saisie des avis du pré jury

Description : Ce cas d’utilisation permet au pré jury ou à la secrétaire d’enregistrer via une

interface les avis du pré jury pour un étudiant et suivant les filières et universités demandées.

Acteurs : Administrateur (secrétaire, jury)

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendu : Aucun

Pré conditions : L’utilisateur doit s’être identifié en tant qu’administrateur

Hypothèses : Aucune

Scénario : Ce cas d’utilisation est lancé à la demande de l’administrateur. Il sélectionne tout

d’abord l’étudiant pour lequel il souhaite enregistrer les avis émis. Ensuite il peut saisir les avis donnés par la pré jury.

Flux Sortant : Les avis concernant un vœu sont enregistrés dans la base.

· Mise à jour de l’avancement

Description : Ce cas d’utilisation permet à un administrateur de mettre à jour l’avancement

des documents demandés par l’étudiant.

Acteurs : Administrateur

Cas d’utilisation inclus : Aucun

Cas d’utilisation étendus : Aucun.

Hypothèses : Aucune.

Pré conditions : L’utilisateur est identifié en tant qu’administrateur.

Scénario : Ce cas d’utilisation est lancé par l’administrateur.

L’administrateur a la possibilité d’effectuer un suivi d’avancement des documents demandés par l’étudiant, ainsi il peut mettre à jour l’état d’avancement des documents.

Flux sortant : Mise à jour de l’état d’avancement d’un document dans la base de données.

Organisation du site

Création de la base de donnée mysql [Henrio]

Création de la structure de la base de donnée

La base de donnée a tout d’abord été crée à partir du diagramme de classes (DC) résultant de l’analyse.

Les tables de jointure, qui n’étaient pas directement modélisées dans le DC, ont alors dû être ajoutées.

Afin de permettre une réinitialisation rapide et précise, un script de création de la BD contenant des requêtes SQL est appelé.

Ces requêtes SQL implémentent les Tables (create table) et leur attribue leurs clés étrangères (alter table avec contraintes) pour les lier.

Tout au long de notre projet, la base de données n’a cessée d’évoluer.

En effet, une analyse préalable ne peut prévoir à l’avance tous les éléments d’une BD, et cela à cause des contraintes liées au code et au développement de l’application.

De plus, de nouvelles fonctionnalités ont été ajoutées au cahier des charges au cours du projet.

Importation de la BD existante

Certaines données contenues dans la BD existante devaient être réutilisées, nous avons donc décidé d’importer certaines tables.

Les tables du type universités et filières nous intéressaient car elles contenaient des informations vérifiées, ce qui nous évitait d’effectuer des recherches et de les valider.

La table des étudiant nous était inaccessible à cause des informations confidentielles qu’elle contient.

Les tables « université », « filière » et leur table de jointure « enseignement » ont donc été importées grâce à une fonctionnalité Access qui permet de mettre les données d’une table dans un fichier « csv ».

Ce fichier contient alors les données qui vont être importées dans notre BD à l’aide d’un script spécifique.

Données importantes et jeu d’essai

Le site ne peut être opérationnel sans données supplémentaires telles que la liste des Ecoles d’ingénieurs et des Licences pro. Toutes ces données ont dû faire l’objet de recherches personnelles avant d’être insérés dans la BD.

Un petit jeu d’essai est également chargé par un script lors de l’initialisation de la BD, il ajoute automatiquement des utilisateurs et des vœux d’étudiant. Cela nous permet de tester rapidement les différentes fonctionnalités du site sans perdre du temps a ressaisir à la main un jeu d’essai.

En effet la base de donnée a été réinitialisée un grand nombre de fois pour différentes raisons (modification dans la BD elle-même, test d’une fonctionnalité de suppression…), nous avons ainsi gagné un temps précieux.

Tous ces scripts servant à initialiser la BD se trouvent dans le fichier « /initDB/index.php ».

Les requêtes SQL contenant la structure (schéma) de la BD se trouvent dans « /initDB/schema.php ».

La liste des Ecoles et des Licences pro se trouvent dans le fichier « /initDB/predonnees.php ».

Tous les fichiers csv sont dans « /initDB/importer/ ».

Problématique et choix techniques [WALTER]

La problématique de ce projet était de plusieurs natures :

Une application multi-utilisateurs

Il était nécessaire de concevoir un système qui soit accessible à différents utilisateurs :

Les étudiants doivent pouvoir saisir eux-même leurs voeux.

L'administration doit pouvoir gérer ces voeux, afficher des récapitulatifs, imprimer des états et entrer les avis du pré-jury pour chaque voeu universitaire.

Les professeurs doivent pouvoir consulter les documents demandés les concernant.

Par conséquent, cette application doit être accessible depuis les différents postes du département informatique, aussi bien au le secrétariat que dans les « salles machines » étudiantes.

Une application ouverte

Certaines données sont indispensables au fonctionnement de l'application :

· La liste des étudiants autorisés à saisir leurs voeux, ainsi que leurs informations personnelles (Nom, prénom, n° d'étudiant).

· Les notes des étudiants nécessaires pour le pré-jury.

· Les données de l'application existante (universités et filières, écoles d'ingénieurs, licences professionnelles).

Une application sécurisée

Etant donné que notre application accède à certaines données sensibles (notes des étudiants, mots de passe, avis du jury), il faut qu'elle intègre des mécanismes de sécurité pour éviter d'éventuelles tentatives de fraudes.

Pour répondre à cette problématique, nous avons tout d'abord pensé à améliorer l'application existante. Cependant, Microsoft Access ne permet pas la gestion multi-utilisateurs (du moins, nous n'avons pas appris à la mettre en oeuvre), nécessite d'avoir l'application installée sur tous les postes de l'iut (sous la même version), et ne permet pas toujours de créer des interfaces utilisateurs avancées.

Ces raisons nous ont ammené à penser qu'il serait plus utile de créer une nouvelle application plutôt que de tenter d'améliorer la base Access dont Mme Ravi ne se sert qu'occasionnellement parce que ce système n'est pas bien adapté à ses besoins.

En effet, l’application existante couvre tous les départements de l'IUT de la même manière. Le développement d'une solution personnalisée pour le département informatique permet d'être plus proche des besoins et des spécificités des poursuites d'études dans ce département.

Nous avons opté pour la création d'un site Web dynamique* reposant sur le langage PHP et le SGBD* MySQL, qui correspondent parfaitement à la problématique posée :

· La gestion des différents utilisateurs est aisément réalisable par programmation. Le site peut être accessible depuis n'importe quel poste informatique connecté au réseau et doté d'un quelconque navigateur web.

· PHP est un langage ouvert qui offre d'énormes possibilités d'importation et d'exportation de données dans un grand nombre de formats (CSV*, PDF, Excel, Word...).

· La sécurité est accrue, car contrairement au système Access, les données sont enregistrées sur un serveur distant et non sur le poste de l'utilisateur.En contrôlant chaque donnée saisie par l'utilisateur et en programmant un système de droits d'accès, on peut garantir un niveau de sécurité correct.

Organisation générale du site [WALTER]

L’organisation de notre site est assez particulière.

En effet, les sites s’organisent souvent de la manière suivante :

Habituellement, chacune des pages d’un site contient :

· Du code pour identifier l’utilisateur

· Du code pour se connecter à une base de données

· Des données de mise en page (position du menu, des titres…)

· Des requêtes effectuées directement sur la base de données

· Le contenu propre à chacune des pages

Ceci afin d’obtenir une certaine homogénéité des pages.

L’avantage de ce système est qu’il est simple à mettre en œuvre.

Les inconvénients sont une grande redondance du code et la difficulté de maintenir le site.

Une alternative consiste à utiliser la fonction include() de PHP qui permet d’inclure certaines parties du code depuis un fichier partagé entre différentes pages :

Cette méthode évite la redondance du code, mais pas totalement. En effet, chacune des pages doit contenir certaines instructions pour inclure chaque fichier partagé.

De plus, l’utilisateur accède directement à chacune des pages et peut deviner l’organisation du site en lisant dans le champ d’adresse de son navigateur, ce qui peut poser certains problèmes de sécurité :

Nous avons finalement opté pour l’organisation suivante :

L’utilisateur appelle toujours la même page, index.php. Il ignore tout de la structure interne du site, car il est possible de changer de répertoires les pages.

Index.php se charge d’identifier l’utilisateur, de vérifier ses droits d’accès et de les comparer avec la page qu’il demande (par l’intermédiaire du paramètre ?p=NomDeLaPage).

Si les droits correspondent, index.php charge en mémoire la page demandée.

Chaque page, à l’exception de index.php, est en un objet qui hérite de la classe Page, et qui ne fait que redéfinir ses attributs (titres, contenu).

Ainsi, une page contient uniquement ses propres données, il n’y a aucune redondance du code, et le site reste facile à maintenir.

Enfin, chaque page accède à la base de données par l’intermédiaire d’une classe d’abstraction de base de donnée, ce qui permet une plus grande généricité du code : on peut ainsi sans difficulté adapter le site pour un autre système de base de données (Oracle, par exemple).

Les notions de constructeurs et d’héritage existent depuis la version 5 de PHP. Nous avons exploité au maximum ces nouvelles fonctionnalités.

La gestion des utilisateurs[WALTER]

L’identification

L’identification et la déconnexion des utilisateurs est gérée par la page « identification.php ».

Cette section est particulièrement sensible, et nous avons cherché la méthode la plus sécurisée possible pour identifier les utilisateurs :

La première fois qu’un utilisateur se connecte au site, il est considéré comme un « visiteur » qui n’a accès qu’à la partie informative du site.

Il peut à tout moment entrer les informations nécessaires à son identification : son login* et son mot de passe.

En cliquant sur « go », l’utilisateur est redirigé (sans qu’il s’en rende compte) vers la page identification.php, qui examine les informations transmises par l’utilisateur et vérifie l’existence de l’utilisateur dans la base de données, à l’aide de la méthode statique recherche() de la classe User :

Cette méthode vérifie l’existence de l’utilisateur dans la base de données à l’aide de la requête suivante :

Si cette requête renvoie un résultat, cela signifie que l’utilisateur s’est correctement identifié. Un objet Etudiant, Professeur ou Administration est alors créé et enregistré dans la session de l’utilisateur, et ce jusqu’à ce qu’il se déconnecte ou ferme la fenêtre de son navigateur.

Si la requête ne renvoie aucun résultat, l’utilisateur est immédiatement redirigé sur la dernière page qu’il consultait, en lui affichant le message suivant :

Les droits d’accès

Dès que l’utilisateur est correctement identifié, il est nécessaire de déterminer à quelles pages il a le droit d’accéder.

Ce traitement s’effectue grâce à la méthode .

Dans la base de données, les droits sont stockés de la manière suivante :

A chaque consultation d’une page, une vérification est effectuée par index.php afin de s’assurer que l’utilisateur a bien le droit de visualiser la page.

Si ce n’est pas le cas, l’erreur suivante lui est retournée :

Ce mécanisme de vérification systématique des droits d’accès garantit la sécurité du site.

Comme M. Daniel Guillaume nous l’a suggéré au moment de la démonstration d’une pré version du site, nous avons créé une interface permettant à l’administration de modifier à tout moment les droits d’accès aux différentes pages :

Les optimisations [WALTER]

Etant donné que ce site sera réellement utilisé, nous avons optimisé le site de différentes manières, afin de garantir sa stabilité même lorsqu’un grand nombre d’utilisateurs y sont connectés :

Les requêtes

Chaque requête à la base de donnée a été optimisée individuellement, à l’aide de nos connaissances acquises au cours de ces deux années à l’IUT, mais aussi grâce aux conseils avisés de M. Fessy qui nous ont été d’une grande aide.

Afin de faciliter le développement, nous avons intégré à la classe gérant notre base de données des fonctions de benchmarking* afin de repérer les requêtes les plus lourdes :

Les requêtes qui pu être fortement optimisées sont les suivantes :

· La requête effectuée sur chacune des pages de l’administration, qui permet de rechercher le nombre d’établissements, de filières et d’écoles d’ingénieurs non approuvées :

SELECT ( SELECT count('fil.id_fil') FROM FILIERE fil WHERE conf_fil='non' ) AS NB_FIL, ( SELECT count('ens.id_fil') FROM ENSEIGNEMENT ens WHERE conf_ens='non' ) AS NB_ENS, ( SELECT count('univ.id_univ') FROM UNIVERSITE univ WHERE conf_univ='non' ) AS NB_UNIV, ( SELECT count('eco.id_eco') FROM ECOLE eco WHERE conf_eco='non' ) AS NB_ECO, ( SELECT count('pro.id_pro') FROM LICENCE_PRO pro WHERE conf_pro='non') AS NB_PRO FROM PARAMETRE

· La requête qui permet d’afficher le tableau récapitulatif selon des critères de tris et de filtres bien précis :

#VOEUX UNIVERSITAIRESSELECT v.num_etud as ETU_NUM, (f.conf_fil=true AND un.conf_univ=true AND ens.conf_ens=true) AS CONF,v.avis_voeu as VOEU_AVIS, f.lib_fil as VOEU_FIL, f.miage_gmi as MIAGE_GMI, un.lib_univ as VOEU_UNIV, NULL as VOEU_ECO_AVIS, NULL as VOEU_ECO_LIB, NULL as VOEU_PRO_AVIS, NULL as VOEU_PRO_LIB FROM (VOEU v INNER JOIN FILIERE f ON f.id_fil=v.id_fil INNER JOIN UNIVERSITE un ON un.id_univ=v.id_univ INNER JOIN ENSEIGNEMENT ens ON ens.id_univ=un.id_univ AND ens.id_fil=f.id_fil)

UNION SELECT #VOEUX ECOLESve.num_etud as ETU_NUM, (e.conf_eco=true) AS CONF, NULL, NULL, NULL, NULL,ve.avis_eco as VOEU_ECO_AVIS, e.lib_eco as VOEU_ECO_LIB, NULL, NULLFROM VOEU_ECO ve INNER JOIN ECOLE e ON ve.id_eco=e.id_eco

UNION SELECT #VOEUX LICENCES PROvp.num_etud as ETU_NUM,(l.conf_pro=true) AS CONF, NULL, NULL, NULL, NULL, NULL, NULL, vp.avis_pro as VOEU_PRO_AVIS, l.lib_pro as VOEU_PRO_LIBFROM VOEU_PRO vp INNER JOIN LICENCE_PRO l ON vp.id_pro=l.id_pro

Les accès à la base de données

Nous avons limité autant que possible les accès à la base de données, qui consomment généralement beaucoup de ressources.

· Plutôt que de recharger à chaque page les droits de l’utilisateur, nous les enregistrons dans une session

· Nous utilisons à plusieurs reprises des mécanismes de « cache » permettant d’enregistrer les résultats de certaines requêtes et de s’en resservir plus tard. Ce mécanisme a entre autres été utilisé pour le rapatriement des vœux d’un étudiant.En effet, lorsqu’un étudiant se connecte, la liste de ses vœux est une première fois chargée :

#VOEUX UNIVERSITAIRESSELECT v.num_etud as ETU_NUM, v.id_voeu as VOEU_ID, v.date_crea as VOEU_DATE, v.avis_voeu as VOEU_AVIS, f.lib_fil as VOEU_FIL, f.miage_gmi as MIAGE_GMI, un.lib_univ as VOEU_UNIV, NULL as VOEU_ECO_AVIS, NULL as VOEU_ECO_LIB, NULL as VOEU_PRO_AVIS, NULL as VOEU_PRO_LIB FROM (VOEU v INNER JOIN FILIERE f ON f.id_fil=v.id_fil INNER JOIN UNIVERSITE un ON un.id_univ=v.id_univ) WHERE v.num_etud = "20212"

UNION SELECT #VOEUX ECOLESve.num_etud as ETU_NUM, ve.id_eco as VOEU_ID, ve.date_crea as VOEU_DATE, NULL, NULL, NULL, NULL,ve.avis_eco as VOEU_ECO_AVIS, e.lib_eco as VOEU_ECO_LIB, NULL, NULLFROM VOEU_ECO ve INNER JOIN ECOLE e ON ve.id_eco=e.id_eco WHERE ve.num_etud = "20212"

UNION SELECT #VOEUX LICENCES PROvp.num_etud as ETU_NUM, vp.id_pro as VOEU_ID, vp.date_crea as VOEU_DATE, NULL, NULL, NULL, NULL, NULL, NULL, vp.avis_pro as VOEU_PRO_AVIS, l.lib_pro as VOEU_PRO_LIBFROM VOEU_PRO vp INNER JOIN LICENCE_PRO l ON vp.id_pro=l.id_pro WHERE vp.num_etud = "20212"

Cette requête étant relativement imposante, nous enregistrons ses résultats dans la session de l’étudiant afin de ne l’exécuter qu’une seule fois.Ainsi, si l’étudiant recharge la même page, il ne sera pas nécessaire de ré exécuter cette requête.

LOT ETUDIANT

Interface « consulter voeux » [hassanaly]

L’interface « consulter vœux » permet aux étudiants de visualiser ses vœux de poursuite d’étude à tout moment.

L’interface regroupe les vœux universitaires, les vœux d’écoles et les vœux de licences professionnelles de l’étudiant sur une seule page.

La date et l’heure de l’ajout d’un voeu y sont mentionnées.

Si l’administration le décide (paramètre à activer dans la gestion de l’administration du site), l’étudiant peut aussi visualiser les avis attribués à ses vœux par le jury.

L’interface lui permet aussi de supprimer un vœu.

Il lui est possible de consulter les documents demandés pour chaque vœu (ainsi que les enseignants concernés pour le traitement de ces documents et leur date butoir), avec la possibilité de savoir ci ceux-ci ont été traités par l’administration ou non.

Pour visualiser les documents du voeu Pour supprimer le vœu

(sur click)(sur click)

LOT ADMINISTRATIF

Réalisation de la fonctionnalité du tableau récapitulatif (ainsi que filtres et tris) [penet]

Madame Ravi avait formulé le besoin d’un tableau récapitulatif permettant de visualiser l’ensemble des vœux, pour chaque étudiant, ceux-ci séparer en 4 catégories: miage/gmi, licences universitaires classiques, écoles d’ingénieur et licences professionnelles.

Pour réaliser ce tableau nous nous sommes basés sur celui que madame Ravi réalisait auparavant elle-même sur Excel. L’intérêt de cette fonctionnalité est que ce tableau soit généré automatiquement vis-à-vis des vœux enregistrés dans la base de données.

Le développement de ce tableau a été ordonné en deux principales étapes, la première étant de le générer automatiquement et la seconde étant de réaliser des options de tri et de filtrages.

La génération automatique nous a posé problème principalement au niveau des requêtes SQL. En effet pour récupérer les différents vœux nous avions besoins d’interroger 3 tables différentes (vœu universitaire, vœu en école et vœu en licence professionnelle). Or lorsque les étudiants doivent formuler leurs vœux, les vœux universitaires comprennent les licences classiques et les vœux de type miage/gmi. Nous avons donc créé un attribut (miage/gmi) dans la table des filières universitaires nous permettant de distinguer ces poursuites d’études particulières.

L’interrogation des 3 tables de manière simultanée a été possible grâce à l’union de 3 requêtes distinctes.

La seconde phase de développement des options de tri et de filtrage a été la plus compliquée à mettre en œuvre. En effet, pour réaliser cette fonctionnalité, nous avons du modifier l’ensemble de l’organisation de nos requêtes SQL pour qu’elles puissent être flexibles en fonction des options sélectionnées. Ceci a été possible en décomposant nos requêtes en différents paramètres définis en fonction des tri et filtres sélectionnés.

Les variables ici mises en surbrillance, permettent d’adapter la requête de récupération des vœux aux filtres et tris choisis.

Les différentes options de tri sont par ordre croissant ou décroissant :

· Par nom d’étudiant

· Par numéro d’étudiant

· Par note d’étudiant : ceci sur leur moyenne générale, leur moyenne sur l’UE1, UE2 ou UE3 et ceux-ci sur les 2 années.

Les différents filtres disponibles sont :

· Sur une université

· Sur une école

· Sur une licence professionnelle

Les filtres et tris peuvent être appliqués simultanément. On peut donc visualiser pour une école d’ingénieur la liste des étudiants, l’ayant demandée, triée sur les moyennes dans l’UE2 par exemple (contenant entre autres les mathématiques).

Cette fonctionnalité nous semble bien répondre au besoin de madame Ravi. Cependant il est à préciser que le tableau est plus important en terme de taille que celui réalisé sous Excel car moins synthétique. En effet, nous ne pouvions (d’un point de vue technique) résumer tout les vœux d’un étudiants sur une seule ligne comme c’était le cas. Il est à noter que si un enseignement n’est pas approuvé par la secrétaire, celui-ci apparaîtra en rouge.

Aperçu du tableau récapitulatif

Au niveau des tests, nous avons vérifié que le tableau restait cohérent, synthétisait bien les différents vœux effectués et permettait bien de distinguer les différents étudiants.

Ainsi nous avons pu constater que le tableau restait lisible même lorsque de nombreux vœux étaient formulés par étudiant.

Réalisation des fonctionnalités de gestion des établissements, gestion des filières et de gestion des enseignements [penet]

Cette fonctionnalité est nécessaire puisque les étudiants saisisses eux-mêmes leurs vœux et ont la possibilité d’ajouter des universités (écoles, licences professionnelles, filières ou enseignement) qui ne sont pas encore répertoriées dans la base de données. C’est pourquoi il est nécessaire que ces informations soient vérifiées et validées par une personne gérant les poursuites d’études.

Ces fonctions permettent de gérer intégralement les différentes informations concernant les différents. En effet les informations pour une université, école ou licence professionnelles sont importante et doivent être mises à jour puisqu’elles sont présentées dans la partie informative du site.

La fonctionnalité de modification des établissements permet donc de saisir diverses informations telles que leurs noms, leurs adresses complètes, leur numéro de standard et de fax, leur email de contact et l’adresse du site Internet.

Il est également possible de remplacer l’établissement, ou la filière par un établissement (ou filière) existant ainsi si l’élément saisi par un étudiant correspond à un élément déjà existant, le gestionnaire peut le remplacer sans altérer les vœux effectués.

Affichage des différents établissements et fonctionnalités associées

Une autre fonctionnalité est d’approuver directement les éléments ajoutés si le gestionnaire sait que cet élément n’existait pas dans la base et doit donc y être inséré.

Il est également possible d’ajouter un établissement ou une filière, via le formulaire ci-dessous ainsi un nouvel établissement pourra être ajouté par la responsable administrative ce qui lui évitera par la suite d’avoir à approuver les ajouts des étudiants.

Formulaire de saisie d’une nouvelle université

D’un point de vue technique, cette partie s’est avérée très importante. En effet l’utilisation régulière de cette rubrique est nécessaire afin d’entretenir une base de données propre. En effet les étudiants pouvant ajouter eux-mêmes des universités, des filières ou des liens (enseignements) nouveaux entre celles-ci, la base de données contiendra des données ajoutées par de nombreux utilisateurs.

C’est pourquoi cette gestion est nécessaire afin que les données ajoutées soient validées ou supprimées. Les modifications des données par l’administrateur entraîneront une répercussion sur la partie informative et surtout sur les vœux correspondants. Une fonctionnalité d’alerte par mail est disponible, lorsque celle-ci sera activée, les modifications apportées aux vœux des étudiants leur seront directement communiquées.

Gestion des documents [henrio]

La fonctionnalité « Gestion des documents » permet d’avoir un aperçu de tous les documents demandés par les étudiants.

Ces documents sont présentés dans la catégories des vœux auxquels ils appartiennent : Université, Ecole et Licence pro.

Le traitement des dossiers d’inscription par l’administration est grandement simplifié grâce à différentes fonctionnalités :

· Chaque dossier (ensemble de plusieurs documents pour un vœu) peut être suivi grâce un l’affichage de son état (« traité » ou « non traité »).

· Le tri des documents par date : les documents les plus urgents sont placés en haut de leur catégorie.

La section « Gestion des documents » a été conçue afin de répondre aux besoins de Mme Flandrin.

Les documents doivent souvent être complétés par des professeurs et ceci avant une date limite.

Nous fournissons donc à Mme Flandrin et Mme Ravi, voir aussi aux professeurs, la possibilité de consulter rapidement les documents non traités et de modifier leur état.

Cette fonctionnalité n’implique aucune grande difficulté, si ce n’est le « tri par date » des documents. En effet la date butoir est indiquée par l’étudiant, elle est donc sous la forme d’une chaîne de caractères, il est alors impossible d’effectuer un tri par date croissante ou décroissante avec une requête SQL.

Nous avons donc crée et chargé les documents et leur date dans un tableau PHP pour convertir ces dernières en secondes (timestamp unix). Apres le tri, les dates sont reconverties pour l’affichage.

Les importations[de lemeny]

Importation des Etudiants

La gestion des poursuites d’étude des étudiants ne peut se faire sans une base de données déjà existante d’élève. Bien qu’un système de gestion des étudiants ainsi que de leurs notes soit actuellement en préparation, il nous a été impossible dans l’état actuel des choses de pouvoir mettre en place un système d’importation de base à base. Il nous fallait toutefois pouvoir remplir notre base d’étudiant afin que le site soit opérationnel.

Pour cela nous avons créé un script d’importation d’étudiants. Celui fonctionne à partir d’un fichier .CSV générer par l’application Excel.

En effet, une fois le fichier .csv créer par l’administration selon un schémas bien spécifique fournis à l’avance, il suffit de le sélectionner, et de valider la commande d’importation pour que celle-ci se fasse.

L’application traite alors chaque ligne représentant chacune un étudiant, n’enregistrant dans la base de données que ceux ayant au moins :

· Un numéro d’étudiant

· Un nom

· Un login

On émet l’hypothèse que la liste d’étudiant importé depuis le fichier CSV est cohérente et ne contient pas de doublons.

Il est important d’ajouter qu’avant chaque nouvelle importation, une purge de la base existante est faite.

Importation des notes des étudiants

L’importation des notes des étudiants fonctionne sur le même modèle que celui de l’importation des étudiants.

A partir d’un modèle donné, l’administration créer un .CSV, il valide ensuite l’importation.

Avant de valider complètement, une étape de trie est effectué, celle-ci vérifie l’existence des étudiants avant insertion dans la base de donnée. Les étudiants n’existants pas dans la base des poursuites d’études, ne seront ainsi pas rajouté dans la base.

On émet ici aussi l’hypothèse que la liste soit cohérente.

Gestion de l’opération au niveau du langage :

Le traitement des .CSV se fait à l’aide de la fonction « fgetcsv() » qui permet de lire ligne par ligne le fichier à importer.

while ($note = fgetcsv($handle, 1000, ";")) {

$num = count($note);

if(isint($note[0])){ //éviter les libellés

$this->out.="

// On regarde si le numéro etudiant existe dans la bdd du site ou pas

if(isset($TabEtud[$note[0]]))

Une boucle while permet de parcourir l’intégralité du document et permet de faire des tests sur chacune des données avant importation.

Les paramètres[de lemeny]

Au fur et a mesure du développement du site permettant la gestion des poursuites d’études, de plus en plus de fonctionnalité ont été mise en place.

Afin de permettre une gestion plus simplifié et plus intuitive, nous avons mis en place la page administration. Celle-ci regroupe la plupart des options modifiables par la secrétaire sur le site tel que :

· L’affichage ou non, de la décision du pré jury

· La civilité du directeur de l’IUT

· La date de début de la période de saisie des voeux

· La date de fin de la période de saisie des vœux

· L’activation ou non de l’envoi d’emails aux étudiants

· Le nombre maximum de vœux en école

· Le nombre maximum de vœux possible en université

· Le nombre maximum de vœux possible en licence pro

· Afficher le nombre de voeux dans la partie informative

· Nom du directeur ou directrice de l’IUT

Gestion de la page au niveau organisationnel

Pour gérer les paramètres du site, nous avons mis en place une table a part « PARAMETRE » dans la base de donnée

La décision a été prise de gérer chaque paramètre, non pas par colonne (comme c’est l’accoutumé en général) mais par ligne. Chaque ligne correspond a un paramètre différent dans le site.

Chaque paramètre est composé :

· D’un nom

· D’une valeur

· D’une description

· D’un type (celui-ci permettant de savoir le type de la valeur du paramètre pour permettre son utilisation dans le site)

Afin de pouvoir récupérer les valeurs de chaque paramètre nous utilisons la fonction « getSetting(nom du parametre) » présente dans le fichier « Std ». Celle-ci récupère la valeur du paramètre à l’aide d’une requête.

Affichage de la décision du pré jury :

La décision d’afficher ou non les avis du pré jury dans la partie étudiante revenant à l’autorité de l’administration, nous ne pouvions décider si ceux-ci pouvaient ou pas être consultable. Afin de régler ce problème (qui est plus un problème décisionnel que d’algorithme) nous avons mis en place une option permettant leurs affichages selon les bons vouloirs de l’administration.

if($Std->getSetting('AFF_AVIS')){

if($voeu->getAvis()=='oui') $status='APPROUVÉ';

else if($voeu->getAvis()=='non') $status='REFUSÉ';

La fonction “getSetting()” récupère la valeur du paramètre ‘AFF_AVIS’, qui permet de savoir si l’on affiche ou pas les avis, puis selon la valeur de « get_Avis() » nous affichons APPROUVE ou REFUSE .

Permettre la saisie des vœux dans une période donnée

La saisie des vœux par un étudiant ne doit pouvoir s’effectuer que pendant une période donnée. Pour gérer ce cas nous avons implémenté dans la page administration deux champs permettant la saisie de début et de fin de période de saisie des vœux pour les étudiants.

Lorsque l’on se trouve dans la période donnée, l’étudiant peut avoir accès à la page « nouveauvoeu » dans le cas contraire il n’y a pas accès du tout, un message lui indiquant qu’il ne se trouve pas dans la période de saisie.

Afin de savoir si l’étudiant a la possibilité de visionner la page de saisie des vœux (c’est-à-dire qu’il se trouve bien dans la période donnée), lors du chargement de la page de saisie d’un vœux nous utilisons la fonction « saisieEtuPossible() » qui renvoie vrai si la date actuelle du serveur se trouve entre la date de début et celle de fin se trouvant dans la base PARAMETRE.

if($Std->saisieEtuPossible()==false && !$User->estDeType(ADMINISTRATION)) $Std->erreur(<<

/!\ Hors période de saisie des voeux /!\

La periode de saisie des voeux débute le {$Std->getSetting('DATE_DEBUT')} et se termine le {$Std->getSetting('DATE_FIN')}

Aucune vérification sur la validité de la période n’est effectué, cette vérification est laissé aux soins de l’administration.

Nombre maximum de vœux par université/licence/école

Un étudiant n’a le droit qu’à un nombre limité de vœux par université/licence pro/école, pour mettre en place cette restriction nous avons implémenté dans la base de données trois lignes dont les valeurs correspondent au nombre maximum de vœux par genre de poursuite d’étude.

La vérification pour chaque étudiant se fait à l’aide d’une requête qui compte le nombre de vœux de l’étudiant dans chaque catégories de poursuite d’étude, ainsi une fois le nombre maximum atteint il ne peut ressaisir un vœux que s’il en supprimer un auparavant.

Réalisation de la fonctionnalité d’impression des documents officiels [penet]

Notre produit devant remplacer celui existant, nous devions recréer les états d’impressions. Ces documents étant officiels nous devions les reproduire sans aucune modification.

Dans un souci de flexibilité certaines informations doivent être paramétrables, en effet, le nom du directeur de l’IUT (actuellement de la directrice) peut changer ainsi que sa civilité.

Les impressions possibles sont donc :

· Les équivalences pour un vœu d’un étudiant

Les documents suivants sont disponibles pour l’ensemble des demandes ou pour les demandes approuvées par le pré jury :

· L’ensemble des demandes classées par filière

· L’ensemble des demandes classées par université

· La liste des demandes classée par étudiant

· La liste des étudiants demandeurs

Il est possible d’imprimer les équivalences uniquement pour un étudiant donné, et d’imprimer le tableau récapitulatif pour le pré jury.

La principale difficulté pour développer cette fonctionnalité venait du navigateur Internet Explorer de Microsoft, en effet il ne gère pas certaines mises en page. Ainsi nous n’avons pas pu mettre certaine page au format paysage telle que celle du tableau récapitulatif. Il faudra donc passer par l’interface du navigateur pour mettre la page d’impression en format paysage. Cette impression étant très utile pour le pré jury qui peut également travailler sur ce document papier.

Les tests nous ont permis de vérifier que chaque état d’impression correspondait bien à celui qui existait sur le produit existant.

Réalisation de la fonctionnalité de saisie des avis du pré jury [penet]

L’enregistrement de l’avis du pré jury était auparavant effectué par madame Ravi sur le produit Access. Cette dernière nous a demandé à ce que l’interface de saisie ne change pas grandement. C’est pourquoi l’interface a été pensée en fonction de l’existant.

Ainsi nous avons développé une interface permettant de saisir les avis du pré jury au cas par cas. Cette solution se justifie également par la possibilité donnée au pré jury de saisir lui-même ses avis, voir même par la possibilité d’utiliser notre produit comme support lors de la tenue du jury. En effet, l’interface permet de visualiser les mêmes informations que sur le tableau récapitulatif mais par étudiant, l’étude pouvant donc se faire au cas par cas.

La réalisation de cette page a donc été pensée pour permettre de visualiser toutes les informations contenues sur le tableau récapitulatif sans la contrainte de synthèse.

C’est pourquoi elle contient la majorité des informations d’un étudiant, ses notes, et l’affichage de l’intégralité de ses vœux. Le jury ou l’administrateur peut alors approuver les vœux, et directement imprimer les « demandes d’équivalence ».

La navigation entre les différents étudiants est possible de deux manières, la première étant grâce aux boutons « précédant » et « suivant », permettant de naviguer entre les étudiants par ordre alphabétique. La seconde permet de sélectionner un étudiant dans la liste ceci permettant d’atteindre n’importe quel étudiant.

Aperçu de la page permettant au jury de saisir ses avis

La seule différence se situe au niveau de la présentation des vœux, en effet, la fonctionnalité ayant été demandé dans un premier temps uniquement pour saisir les avis et non pour assister le jury lors de sa décision, les vœux de type miage/gmi ne sont pas différenciés des vœux universitaires « classiques ».

Il est également possible de modifier les notes d’un étudiant, cette fonctionnalité a été ajoutée dans le cas ou les notes d’un étudiant étaient faussée, il n’est pas nécessaire de recharger l’intégralité des notes.

D’un point de vue technique cette partie nous a demandé une application particulière puisqu’elle fait appelles à différentes classes PHP, telles que les classes étudiant et vœu. Chacune de ces classes permettent une gestion organisée des données, ainsi chaque vœu est enregistré dans un objet vœu de cette classe, il en est de même pour les étudiants également associés à un objet.

Lot Informatif

Avant que l’étudiant ne formule ses vœux de poursuite d’études sur l’interface qui lui est dédiée, il est nécessaire qu’il soit informé sur les voies d’études qui lui sont accessibles après le DUT Informatique. Nous avons donc décidé de développer une partie informative accessible à toute personne qui rentrera sur le site de gestion de poursuites d’études.

Le lot informatique se distingue en 2 parties majeures : La recherche d’informations en un premier temps puis le développement de la section informative sur le site.

La recherche d’informations[Hassanaly]

Le site laissant aux étudiant le choix de saisie de 3 types de vœux distincts, la recherche d’information s’est portée sur ces 3 types de voies : les universités, les écoles et les licences professionnelles.

Les voies de poursuites d’études

Les universités

L’idée des le départ fut de proposer un classement intuitif qui permettra aux étudiants de visualiser les informations essentielles selon deux critères :

· Les universités qui proposent une filière donnée : Classement université par filière.

· Les filières que propose une université donnée : Classement filière par université.

Une première démarche évidente consistait à récupérer de l’ancienne Base de Donnée Access les universités recensées ainsi que les filières associées par l’intermédiaire de requêtes SQL.

Dans le but de permettre à l’étudiant de repérer et contacter rapidement les universités par l’intermédiaire du seul site de poursuite d’étude, il était essentiel de retrouver l’adresse postale et Internet de chaque université, leur numéro de fax et téléphone, ainsi que l’email du secrétariat.

Nous avons utilisé le moteur de recherche Google pour récupérer les sites web de chaque université afin d’y collecter ensuite les informations citées ci-dessus.

Les grandes écoles

Pour les écoles nous avons procédés d’une façon similaire : Pour avoir une liste d’écoles d’ingénieurs les plus demandées après le DUT informatique, la recherche s’est faite essentiellement par l’intermédiaire du moteur de recherche Google :

Le site de l’Onisep http://62.62.140.26:8080/national/atlas/html/atlas_sup/dom/cadredom.htm, de l’éducation nationale http://www.education.gouv.fr/sup/grdecole.htm et d’autres sites proposant un palmarès des grandes écoles informatiques nous ont permis d’établir une liste d’écoles d’ingénieurs les plus demandées après le DUT Informatique.

Il fallait ensuite retrouver les informations essentielles sur chaque écoles (adresses etc..), et éventuellement les filières ou options proposées par ces écoles.

Nous avons décidés de les classer en deux catégories : Les grandes écoles publiques et les grandes écoles privées.

Les licences professionnelles

Après une recherche sur les différentes licences professionnelles de Paris et sa région, on peut en distinguer deux types dans le secteur informatique : les licences pro Systèmes Informatiques et Logiciels qu’on note SIL et les licences pro Réseaux et Télécommunications qu’on note RT.

Les options sont variables selon les licences pro : intégration de services internet/intranet, Administration réseaux etc…

Nous avons donc opéré à un classement par type et option de licence pro.

Les informations additionnelles recherchées ont été l’université et le lieu exact de l’enseignement de la licence pro, un numéro de téléphone et l’adresse web correspondante.

Questions supplémentaires

A la demande du professeur d’Economie Gestion Organisation Mr Alban, nous avons pensé à développer une partie qui traitera les différentes questions les plus fréquemment posées par les étudiants.

Mr Alban a fait remplir une feuille aux étudiants de ses 2 groupes de TD où ces derniers mentionnaient des questions à propos des poursuites d’études.

Une fois en possession de ces questions nous les avions transmises à Mme Flandrin qui a eu l’amabilité de répondre à toutes ces questions.

Implémentation de la partie informative sur le site [hassanaly]

Accessible à tous, la section informative est implantée dans le menu du site.

Il sera visible en permanence aussi bien lors d’un accès étudiant que lors d’un accès administration.

Il proposera un menu interactif regroupant :

· une section « Universités »

· une section « Ecoles »

· ne section « Licences professionnelles

· une section Questions/Réponses

Ces sections sont entièrement dynamiques car elles sont intégralement alimentées par la base de donnée, elles sont donc évolutives.

Les voies de poursuites d’études

Le menu « Universités » est déroulant

Il se divise en 3 sections correspondant aux 2 types de classements «universités par filière» et «filières par université» et une section «Adresses » listant les Universités référencées et leurs coordonnées.

La section « Universités »

Universités par filière :

Regroupe toutes les universités d’une filière donnée.

Toutes les filières et les universités enseignant cette filière y sont listées.

Ainsi lors de la création d’un nouvel enseignement par la secrétaire (par approbation de la liaison d’une filière à une université donnée), une ligne mentionnant l’université enseignant cette filière sera automatiquement rajoutée à cette section de la partie informative.

(2) Sur click emmène l’utilisateur sur le site

Internet de l’université correspondante.

(1) Ce lien emmène l’utilisateur sur

la section « Adresses » à

l’emplacement exact de l’université

correspondante :

Le lien qui redirige automatiquement sur la ligne décrivant l’adresse de l’université est réalisé au niveau du code par un système d’Ancrage html: voir aperçu du code sur le schéma ci-dessus.

Filières par université :

Regroupe toutes les filières d’une université donnée.

De manière similaire au classement des universités par filière, toutes les universités et les filières correspondantes de la base de donnée y sont listées ; lors de la création d’un nouvel enseignement par la secrétaire (liaison d’une filière à une université) cette information sera automatiquement rajoutée à la section.

CF (1)

CF (2)

Cette indication n’est affichée que si le paramètre « afficher le nombre de vœux » est fixé à « oui » par l’administration : il indique alors le nombre de vœux étudiants formulés pour cette université.

Il est important de noter que les informations concernant les universités ne seront ajoutées automatiquement à la partie informative seulement si la secrétaire décide de rajouter les informations complémentaires tel que l’adresse (postale,web,mail), le numéro de téléphone etc.. correspondantes à la nouvelle université.

Les tris universités par filières et filières par université sont réalisés simplement grâce aux requêtes SQL.

Pour avoir les universités par filière donnée on réalise la double requête suivante :

$DB->requete(array("SELECT"=>"SELECT id_univ,lib_univ,web_univ,adr_univ FROM UNIVERSITE WHERE id_univ IN (SELECT id_univ from ENSEIGNEMENT WHERE id_fil ='{$data['id_fil']}')"));

Pour avoir les filières d’une université donnée on réalise la double requête suivante :

$DB->requete(array("SELECT"=>"SELECT id_fil,lib_fil,conf_fil FROM FILIERE WHERE id_fil IN (SELECT id_fil from ENSEIGNEMENT WHERE id_univ ='{$data['id_univ']}')"));

La section « Ecoles »

Cette section liste les grandes écoles avec un classement en 2 catégories : Les écoles publiques et les écoles privées.

Ainsi lors de la modification ou l’ajout d’une nouvelle école par la secrétaire ou l’étudiant, la secrétaire pourra préciser la catégorie de l’école, ainsi que les divers informations complémentaires tel que l’adresse de l’école, le numéro de téléphone, le nom complet de l’école dans la partie « gestion des établissements » du site, et c’est seulement après cet apport d’informations que l’école sera automatiquement inscrite dans la section informative du site classée selon qu’elle soit publique ou privée.

De plus, lorsque l’on disposera de l’information concernant les filières ou options enseignées par l’école (si éventuellement renseignées par la secrétaire dans la gestion des établissements), on trouvera un champ « filières » dans les informations sur l’école.

L’école est renseignée par son sigle et par son nom complet.

Un click sur le libellé de l’école renvoi l’utilisateur sur leur site Internet.

La section « Licences professionnelles »

La section des licences professionnelles est alimentée de la même façon que celle des écoles. En voici un aperçu :

la Foire aux Questions

Les questions sont classées en 4 catégories : les questions concernant les MIAGE, celles concernant les écoles, celle concernant les licences et les diverses autres questions.

La partie administrative « gestion de la FAQ » permettra à l’administration de modifier, supprimer ou rajouter des questions/réponses.

Après click sur la rubrique « Questions/Réponses » du menu :

Lors du click sur la question, la réponse apparaît

au bas de la question.

D’un point de vue technique nous avons travaillé sur l’optimisation des requêtes SQL pour la partie informative. Le but était d’extraire les informations nécessaires de la base de données en un minimum de requêtes afin de ne pas encombrer le trafic d’informations sur le réseau.

Dans la partie FAQ par exemple au lieu de faire une requête pour chaque ligne affichée pour avoir la question et la réponse correspondante, nous l’avions optimisée en une seule requête afin que toutes les questions et réponses soient extraites de la base de donnée en une seule opération :

$this->FAQ=array();

$q=$DB->requete(array("SELECT"=> “SELECT c.id_categ, lib_categ, id_faq, question_faq, reponse_faq

FROM CATEGORIE_QUESTION c INNER JOIN FAQ f

ON c.id_categ=f.id_categ"));

while($dt=$DB->fetch($q)){

//ajout de la catégorie si besoin

if(!isset($this->FAQ[$dt['id_categ']])) $this->FAQ[$dt['id_categ']]['LIBELLE']=$dt['lib_categ'];

//ajout de la question/réponse

$this->FAQ[$dt['id_categ']]['FAQ'][]=array("ID"=>$dt['id_faq'], "QUESTION"=>$dt['question_faq'], "REPONSE"=>nl2br($dt['reponse_faq']));

}

Gestion de la faq [henrio]

« Gestion de la FAQ » est une fonctionnalité permettant de modifier, ajouter, ou supprimer du contenu à la section « FAQ » de la partie informative du site.

Nous ne répondons pas cette fois ci à un besoin direct des utilisateurs.

Mais nous avons décidé d’implémenter cette fonctionnalité car elle présentait de nombreux avantages tels que :

· Permettre à l’administration un contrôle total et facile sur le contenu de la FAQ

· Permettre aux professeurs de mettre à jour eux même la FAQ pour répondre aux besoins des nouveaux étudiants.

· Par conséquent attirer plus d’étudiants à consulter le site. Si le site des poursuites d’études propose des informations pertinentes et d’actualité à destination des étudiants, ces derniers, en plus de pouvoir s’informer sur leurs poursuites d’études, feront vivre le site.

· En effet, cet outil ne peut fonctionner correctement si les étudiants ne saisissent pas leurs vœux via le site, son bon fonctionnement est basé sur sa fréquentation.

Deux affichages différents composent « Gestion de la FAQ », un clic sur le lien Ajouter une question-réponse bascule vers l’affichage d’ajout tandis qu’un clic sur le lien Modifier/Supprimer une question-réponse bascule vers l’affichage de modification et suppression.

Ce système de bascules est un choix ergonomique évitant l’ouverture de différentes fenêtres pour les différentes actions.

Ajouter :

L’utilisateur saisi directement la question, la réponse et la catégorie à laquelle la réponse appartient. Un clic sur « Enregistrer » pour valider la saisie.

Modifier/Supprimer :

L’utilisateur sélectionne tout d’abord la question qu’il désir modifier ou supprimer, la sélection se fait grâce à une liste déroulante contenant le début de toutes les questions.

Insérer la question complète dans la liste s’est avéré contraignant du point de vue de l’affichage, il était donc plus simple et plus lisible pour l’utilisateur de n’afficher que le début de la question tout en faisant attention de ne pas afficher une partie trop petite.

Dans le cas d’une suppression, un clic sur le bouton « supprimer ».

S’il désir modifier la question ou sa réponse, il le fait directement via les zones de texte contenant la question et la réponse complète. Le bouton « Enregistrer », identique à celui de la section « Ajout d’une question-réponse » permet d’enregistrer les modifications.

Comme vous pouvez le constater il n’y a pas de bouton « Annuler », c’est aussi un choix ergonomique afin d’apporter à l’utilisateur un sentiment de simplicité et de liberté.

En effet il ne doit pas avoir à réfléchir à la procédure a suivre en cas de retour en arrière, un simple clic sur le menu lui permet de changer de fonctionnalité sans conséquence sur l‘outil.

CONCLUSION[de LEMENY] [PENET]

bilan sur le projet

Notre projet consistait en la création d’une base annexe permettant le suivi des vœux des étudiants pour les poursuites d’études. Après nos entretiens avec les utilisateurs et clients, la décision a été prise de remplacer le produit existant afin de répondre plus efficacement aux besoins des utilisateurs.

Nous avons donc mis en place un nouveau système de gestion des poursuites d’études basé sur les langages PHP et Java script. Le développement d’une telle application répondait à des besoins bien spécifiques de la part de la secrétaire et de la directrice du pré jury, principaux utilisateurs de notre produit.

En effet, notre objectif premier était de faciliter la gestion des poursuites d’études, tant pour l’administration que pour les étudiants. Le recensement des vœux était auparavant une phase non automatisée qui nécessitait de multiples saisies. Désormais la phase de saisie des vœux sera effectuée par les étudiants eux-mêmes, facilitant ainsi la communication entre étudiants et administration.

Suite à ce recensement, madame Ravi réalisait un tableau récapitulatif sous Excel (regroupant vœux et notes de chaque étudiant) à l’intention du pré jury. Ce tableau est dorénavant réalisé automatiquement et peut être imprimé pour le pré jury.

Enfin, une fois les délibérations du jury terminées, la double saisie des décisions par la secrétaire dans le tableau Excel et dans le produit Access existant a été simplifiée puisqu’elle n’est nécessaire qu’une seule fois dans le nouveau produit.

Pour améliorer la communication entre les étudiants et l’administration, un système de suivi des vœux a été mis en place. L’étudiant précise lui-même ses vœux et informe l’administration des documents nécessaires et de la date butoir pour ses demandes. Il pourra ensuite consulter l’avis du pré jury si la direction du département décide d’afficher l’information.

Nous avons également mis en place une partie informative permettant aux étudiants de se renseigner et d’obtenir des réponses aux questions qu’ils se posent fréquemment.

Nous sommes assez satisfaits du travail fourni, puisque nous avons réussi à atteindre les objectifs que nous nous étions fixés. Nous pensons que le site de gestion des poursuites d’études est directement utilisable, à la fois par les étudiants, la secrétaire ainsi que par la présidente du jury.

principaux problèmes rencontrés

Plusieurs problèmes se sont posés à nous : le premier étant de répondre aux besoins des utilisateurs. En effet, nous avons remarqué que les réponses aux problèmes apportés aux utilisateurs ne correspondaient pas toujours aux besoins qu’ils soumettaient. Il fallait réussir à se plier à leurs exigences ainsi qu’à celles imposées par le langage, l’algorithmique ou bien la gestion d’une base de données cohérente (les demandes de l’utilisateur n’étant pas toujours réalisables).

Un autre problème a été de définir précisément les fonctionnalités à mettre en place et le rôle de chacun des acteurs dans les processus réalisés.

bilan humain

Durant la phase d’analyse, nous nous sommes heurtés à quelques difficultés. En effet nous avions chacun des idées différentes sur le fonctionnement du site, mais finalement après avoir analysé chacune d’entre elles, nous avons réussi à nous mettre d’accord pour partir sur un développement qui satisfaisait chacun d’entre nous. Nous avons tous dû faire un effort d’écoute et d’explication afin que le groupe puisse continuer à travailler.

Pendant le déroulement du projet, nous n’avons pas eu beaucoup de problèmes. Chacun des membres du groupe était cantonné à une partie bien spécifique; lorsqu’une importante modification devait avoir lieu, notamment au niveau de la base de données ou de la structure du site, chacun mettait du sien afin de corriger les erreurs qui découlaient forcement de cette modification.

L’intérêt des réunions et discussions était de permettre une bonne cohésion du groupe, afin que les idées de chacun puissent être exploitées ou tout du moins étudiées. Elles nous permettaient de déterminer la meilleure évolution possible du site selon les idées de chacun.

Le projet s’est assez bien déroulé dans l’ensemble; il nous a permis d’appréhender le travail dans un groupe de développement de plus grande envergure que nous ne l’avions vu durant nos deux années d’IUT. La