Un système d'information dédié aux établissements d'enseignements

Dans les TDs nous avons analysé un système de diffusion des informations ce qui nous a conduit à poser les bases d'un “service” central de diffusion des informations.

Dans un deuxième temps, pendant le projet, nous mettrons toutes nos compétences en jeux pour construire un système d'information global.

Chaque binôme choisit une des fonctionnalités ci-dessous. Il doit alors mener la construction de cette fonctionnalité de l'analyse à la mise en oeuvre en passant par la conception, la construction d'une BD, la mise en place d'une IHM, quelques bribes du serveur pour démontrer la cohérence de l'ensemble et l'explicitation des tests réalisés.

Les séances ne sont pas balisées au sens où vous vous organisez comme bon vous semble en fonction des livrables demandés et des jalons qui ont été posés. Nous ne voulons jamais entendre : “qu'est-ce qu'il faut faire?”
Utilisez les jalons pour enchaîner les tâches!

Plusieurs binômes peuvent travailler ensemble si chacun remplit bien la fonctionnalité attendue. Un seul binôme au sein d'un groupe de TP par fonctionnalité.

Vous trouverez ci-après des éléments de code vous permettant de créer un client “interactif” en utilisant ajax.

Nous conseillons vivement l'utilisation d'un Gestionnaire de versions, par exemple googleCode si vous n'en avez pas d'autre.

Les rendus sont échelonnés.

• Vous pourrez modifier les rendus intermédiaires (livrables) pour les améliorer.
• Par contre le planning prévisionnel, donné avec la première version du cahier des charges, n'est évidemment pas modifiable.
• Les fonctionnalités proposées dans le cahier des charges peuvent évoluer (être précisée) mais pas disparaître.
  

Les jalons correspondent à des dates limites non modifiables.

• Les jalons sont posés en nombre de semaines de cours. Pour vous aider des dates ont été ajoutées.
  
• Vous pouvez vous organiser comme bon vous semble tant que vous respectez les délais.
• Par contre, vous devez être préciser exactement la manière dont vous avez travaillé dans votre planning réel.
  

1. Rédaction d'un cahier des charges (voir plan ici) intégrant une planification des tâches et évidemment dans la version initiale pas de partie suivi.
   • Ce cahier des charges sera élaboré en interrogeant des représentants de toutes les parties prenantes extérieures au groupe. Elles seront référencées dans le document final. Une d'entre elles pourra être invitée à la démonstration finale.
   • L'accent devra être mis sur les exigences fonctionnelles et non fonctionnelles.
   • Ce document est susceptible d'évoluer au fil de l'analyse modulo les restrictions données ci-dessus
   • jalon +2sem : 8/11/10
2. Validation de votre cahier des charges par votre encadreur (jalon + 2,5sem)
3. Production des cas d'utilisation & scenarii de niveau analyse
   • jalon +4sem : 22/11/10
   • Attention ce livrable sera noté. Les critères sont entre autres:
     • la spécification détaillée des cas d'utilisation (brève description, flots, priorité)
     • des scenarii de haut niveau mais propres et cohérents. En particulier, la direction des flots à de l'importance.
4. Évolution des diagrammes pour un passage en conception : scenarii clefs détaillés, diagrammes de classes
   • jalon +6sm : 06/12/10 17/12/10 18/12/10 à 12h
   • Éléments d'architecture
5. Explication des choix technologiques
   • Vous pouvez faire des choix pour une version en “production” et justifier d'autres choix dans le cadre du projet
   • jalon +6sm : 06/12/10 17/12/10 18/12/10 à 12h
6. Codes dont (jalon +9sem)¹⁾:
   • Maquette pour les interfaces graphiques : diffusion (prototype : html & css) & administration (au choix, une maquette simple éventuellement non connectée (applet, servlet, autres…))
   • Schéma de bases de données, la cohérence de vos schémas en fonction des traitements prévus sera démontrée
   • Code d'implémentation de certains éléments du serveur
   • Mise en place de tests unitaires (et, pour les plus avancés, d'intégration ( optionnel))
   • jalon +9sm : 3/1/11 Le rendu des codes et des tests réalisés se fera avec le rendu final. Ils doivent néanmoins être opérationnels pour la démonstration.
7. Démonstration des différents points du projet : nous pourrons inviter des parties prenantes à cette démonstration
   • jalon +9sm : 4/1/11
8. Livraison de l'ensemble : Vous pouvez revenir sur tous les rendus intermédiaires pour les rendre cohérents avec le résultat final.

En résumé :

• Le cahier des charges comprenant aussi :
  • le planning réel de votre projet dans la partie suivi du cahier des charges
  • un bilan des retours d'évaluation utilisateurs.
  • les choix technologiques
• Les diagrammes UML
• Le code y compris un README
• Optionnellement, un film de la démonstration
• jalon +10sm : 10/1/11

Chaque binôme choisit une fonctionnalité. Un seul binôme au sein d'un groupe de TP par fonctionnalité.

Pour chaque fonction seules des pistes sont données. Vous devez les approfondir pour déterminer plus précisément leur contenu. Pour certaines fonctions, il faut peut-être restreindre le cahier des charges. Il est vivement conseillé de consulter des parties prenantes…

Exceptionnellement un binôme peut proposer une autre fonctionnalité mais elle devra être discutée avec votre encadreur.

• L'anniversaire d'un étudiant sera annoncé en précisant son année (S1T, S3T,…) , son groupe et ….
• L'anniversaire d'un enseignant ou d'un administratif sera annoncé en précisant seulement son nom.
• Un petit mot pourra être affiché avec l'anniversaire.

• Pour chaque anniversaire, il doit être possible d'ajouter pour une année donnée un petit mot ou de remplacer celui par défaut comme : bon anniversaire par exemple qui deviendrait “Happy Birthday”, aid “milad said” ou “buon compleanno”.
• Attention au caractère privé de certaines données et aux droits de modification des messages etc.

Bien qu'il soit plus raisonnable de se lier à un système existant, vous créerez tous les éléments dont vous avez besoin. Mais vous prendrez bien en compte, le fait que demain on doit pouvoir remplacer certains de ces éléments par un système existant.

Ce sujet est très large. Deux groupes peuvent travailler ensemble sur le sujet en séparant clairement les tâches. Dans le cas contraire, le sujet pourra être réduit et d'autres propositions avancées.

• Dès qu'un groupe est affecté sur un projet l'information est diffusée. Par exemple : sujet “projets tutorés” affecté au groupe : John Doe & Jane Doe
• Lorsqu'il manque un membre à un groupe, il est possible de faire passer un message. Par exemple : Le groupe S.A.L.T recherche un designer sur le sujet “groupes de musique”
• Dès que de nouveaux sujets sont disponibles ils sont affichés. Par exemple : Sujets encore disponibles : “projets tutorés”, “groupes de musique”.
• Dès qu'un projet a été affecté, il n'est plus affiché.
• En période critique, le nombre des étudiants sans projet et éventuellement leur nom sera affiché. Par exemple : 2 étudiants sans projet : John Doe et Jean Tartempion.

Les groupes de projets sont gérés en respectant le protocole suivant :

1. Des sujets sont soumis par des encadreurs,
2. Des étudiants postulent sur les sujets,
3. Le responsable des projets affecte les étudiants
4. Lorsqu'un projet est complet (on ne peut plus lui affecter d'étudiants) il n'apparaît plus dans la liste des projets.

Il s'agit de définir un système de gestion des alarmes.

• Une alarme est une information “textuelle” qui doit être affichée à une date fixe (une heure d'un jour donné, une heure de la journée, toutes les x minutes, …).
• En fonction des types d'alarmes (pause, urgence, rappels, absence, retard, changement d'edt, …) les affichages sont différents.
• Les différents formats d'affichage sont dépendants des clients. Ils ne sont pas gérés au niveau du serveur. En cas de type d'alarme inconnu, un format standard d'affichage est prévu.

• Seul un administrateur peut ajouter une nouvelle alarme.
• Pour des besoins de statistiques, il peut être nécessaire de sortir des topos tels que : “tous les rappels à destination d'un étudiant donné”, “tous les rappels à destination d'un étudiant de 1ère année”, “nombre d'urgence déclenchées par mois”, changements d'edt

• Les informations de ce type seront diffusées uniquement dans la cafétéria.
• Pour une soirée, les informations à prévoir sont au moins quand, où et quoi. Des images peuvent aussi être associées à une soirée.
• Des retours sur les soirées (soft uniquement) pourront être diffusés. Il pourra s'agir de messages (e.g. “Merci pour la soirée aux organisateurs” Les gentlemen) et de photos.

• Il sera interdire d'enregistrer plus d'un soir en semaine comprenant une soirée.
• Plusieurs soirées par soir sont possibles mais un avertissement doit être levé.
• Une soirée a toujours une école/institution organisatrice reconnue par le système.
• Des statistiques devraient pouvoir être extraites.
• Les soirées devront être saisies par un administrateur (il peut s'agir d'étudiants qui engagent leur responsabilité en validant).
• Les messages de retour devront être validés par un administrateur (il peut s'agir d'étudiants qui engagent leur responsabilité en validant).

L'objectif est d'afficher les rendus attendus des étudiants par semestre (S1, S2,…)

• Affichage des rendus attendus avant le rendu final : intitulé, format du rendu, date du rendu, procédé de rendu ou adresse web donnant l'information (e.g. S3 : OMGL2 - cahier des charges -pdf ou doc - voir site web - 15 jours restant)
• Regroupement des rendus par semestre
• Utilisation des couleurs pour visualiser la proximité du rendu
• Des extensions de rendus peuvent apparaître (e.g. retour sur l'intervention du DSI 1 jour + 2 jours)

• Tout enseignant peut enregistrer un rendu.
• Un report de rendu peut être enregistré comme une extension (à visualiser).
• Des statistiques peuvent être prévues pour visualiser la charge de travail dans l'année.

L'objectif est de mettre à disposition des seuls membres de l'établissement, un outil facilitant le co-voiturage. Nous affichons :

• les propositions de co-voiturage du jour et du lendemain,
• les demandes de co-voiturage du jour et du lendemain,
• les propositions/demandes de co-voiturage “loin” longtemps avant,
• bien sûr, si une voiture est pleine, l'information n'est plus affichée
• …

• Seules des personnes bien identifiées peuvent ajouter des propositions et des demandes;
• Une proposition/covoiturage périmée doit disparaître;
• Il faut peut être gérer un système de warning si des demandes/propositions ne sont pas réactivées.
• Des statistiques montrant l'intérêt du système devront être prévues.
• Des contraintes doivent être prévues : une personne ne peut pas être dans deux voitures en “même” temps.

• Afficher le nom des étudiants absents en salle des professeurs (e.g. S1 : Jane Doe, S3 : Néant)
• Afficher le nombre d'absence par étudiant absent du jour dans la semaine et dans le mois (e.g. S1 : Jane Doe (2, 0) , S3 : Néant)
• Afficher le nom des professeurs absents en précisant la durée prévue s'il y a lieu (e.g. Mlle A. Tautou : durée indéterminée ; M. X : ce matin)
• Le nom des étudiants dont le nombre d'absence non justifié dépasse le seuil autorisé apparaissent en rouge.

• La saisie des professeurs absents n'est possible qu'à des personnes autorisées.
• La récupération des absences des étudiants pourra soit correspondre à un “service” offert, soit s'appuyer sur de la récupération d'information dans des fichiers dédiés (à voir avec les parties prenantes).
• Un dépassement d'absences non justifiées déclenche un mail automatique.
• Des statistiques devront être possibles en fonction
  • des justifications valides ou non (e.g. pour maladie, panne de réveil, problème de bus, …)
  • des jours de l'année
  • d'un étudiant donné, distribution dans l'année
  • par matière
  • par créneaux
• Lorsqu'un groupe d'étudiants atteint un nombre critique d'absences, un avertissement est émis par le système

Le bureau des sports veut pouvoir diffuser des informations concernant ses activités :

• Horaires des entraînements
• Annulation des entraînements
• Annonces de rencontre,
• Appels à joueurs,
• Ventes de matériels …
• Chaque type d'information fait l'objet d'un affichage particulier

• La saisie de toutes ces informations doit être supportée par le système.
• Une fiche montrant les entraînements (rencontres) dans l'année par sport doit pouvoir être extraite

Le bureau de la musique veut pouvoir diffuser les informations relatives à :

• Répétitions,
• Annulations de répétition,
• Annonces de soirées,
• Appels à musiciens,
• Bourses aux instruments…
• Chaque type d'information fait l'objet d'un affichage particulier

• La saisie de toutes ces informations doit être supportée par le système.

Voici un ensemble très simple de codes qui vous permettent de tester vos propres codes.

sample.zip

Vous pouvez le tester ici : http://users.polytech.unice.fr/~blay/sample/indexSeduite.html

• data.xml: les données sous forme XML,
• prototype.js: la bibliothèque utilisée, pas nécessaire a priori de regarder dedans,
• index.html: la page de diffusion d'information. Elle contient une div “main”, qui va être utilisée pour l'affichage. Dès son chargement, elle appelle la fonction de récupération des informations
• business.js: le code métier.
  • retrieve: il s'agit de l'appel AJAX permettant de récupérer le contenu de data.xml. Si la récupération réussit, on prend le document XML reçu, on en extrait tous les éléments contenu dans des balises “information”, et on lance la boucle de diffusion sur le premier élément.
  • loop: fonction supportant l'affichage des informations. Si l'index est plus grand que la cardinalité de l'ensemble des information, on a fini ⇒ on se rappelle. Sinon, on récupère l'élément courant, on l'affiche, et on se rappelle dans Delta secondes sur l'élément suivant (window.setTimeout …).
  • display: cette fonction récupère l'auteur et la date (commune à toutes les infos). Le “content” spécifique est transformé en html, et la div “main” de la page web est mise à jour avec ce code.
  • transform: cette fonction identifie l'attribue “kind” de la balise, pioche dans un tableau de binding la fonction à utiliser pour gérer cette information, et fait la transformation.

1. définir comment il se représente en XML,
2. implémenter la fonction de transformation, et la positionner dans le tableau “binding”. La clé utilisée DOIT être celle passée dans l'atribut “kind” de la balise content.

1. remplacer data_url dans business.js par une URL.
2. La mise en place du serveur web lui-même sera discutée en séance en fonction des groupes et de vos connaissances.

“That's all folks. Le reste, c'est du CSS et de la gestion d'erreur. Et vous obtenez Seduite” Sébastien Mosser

• Lestel & Courtade–aprem–
• Nicolas NOTO & Romain Carlot –matin–
• Samy AITTAHAR & Romain FIGLIUZZI –matin–

• Guillaume Adam & Tristan Scaglia –matin–
• Kévin BOGO & Jérémy CHATTON –matin–

• Fabien Belli & Brunel Jérémy –aprem–

• Vincent CHANDELIER & Benjamin PERRET –matin–

• David DA SILVA & Franck MUNIER –matin–

• Alexandra MUGE –aprèm–

• Alexandre BOURSIER & Loïc FAIZANT + Yann BONDUE & Olivier CACCIUTTOLO –aprèm–

• Alexis LAURENT & Roufast –aprem–
• Franck MIRTILLO & Florian OLIVARI –matin–
• Benjamin GARNIER & Pascal CUISINAUD –aprem–

• Papasergio Anthony & Salim Medhy –matin–
• LAVAIL Antoine et TOROSSIAN Sevan –aprem–
• Nolan POTIER & Emmanuel SHIMABUKURO –aprem–

• Edouard Garraud & Gilles Miraillet –matin–
• Ladsous & Turchi – aprem –
• Clément ROURE & Loïc WILLAUME –matin–
• Joris HARNETIAUX & Cécile MARTIN – aprem –

• Agnamazian Katia et Paeta Suzy–aprem–