Skip to topic | Skip to bottom
Home
Linfo
Linfo.ProjetDevt2009r1.19 - 09 Apr 2009 - 11:31 - PhilippeCollettopic end

Start of topic | Skip to actions

Projet de développement (2008-2009)

Fiche signalétique

Volume : 6 * 2h de cours, 6 * 2h de TD par sujet (5 sujets).

Parcours : Informatique (obligatoire), MIAGE (obligatoire)

Semestre : 6

Objectif : Réalisation, en équipe, d'un développement logiciel de taille conséquente à partir d'un cahier des charges et d'une architecture préétablis.

Intervenants

Cours : Philippe Collet (coordonnateur du module).

TD/suivi des projets : Philippe Collet, Michel Gautero, Gilles Menez, Philippe Renevier.

Programme

Outils

Voir directement sur la page ProjetDevt2009Outils

Evaluation

Modalités de déroulement

Ce module fait réaliser en équipes (idéalement 4 personnes et 4 personnes maximum) un développement logiciel de taille non négligeable, en focalisant sur l'organisation du développement (découpage en taches) et la qualité (tests unitaires)

Les modalités de déroulement sont les suivantes :

  • Les équipes sont formées par consensus par les étudiants.
  • Il y a 5 sujets dans 3 langages différents (C, Java, PHP/MySQL).
  • Chaque sujet est encadré par un enseignant tuteur, pour environ 4 équipes.
  • Après publication des sujets (cf. calendrier) chaque équipe, préalablement formée, emet une liste de 3 choix ordonnés au coordonnateur (ALERT! les étudiants MIAGE doivent forcément choisir des sujets en Java ou PHP/MySQL).
  • Le coordonnateur répartit les sujets entre les équipes, en essayant de satisfaire leur choix, mais un sujet parmi les 3 choix n'est pas assuré pour chaque équipe. Les étudiants n'ayant pas répondu sont automatiquement placés pour compléter des équipes ou en former de nouvelles.
  • Des cours sont dispensés au préalable sur les principes et les outils à utiliser.
  • Une fois le sujet attribué à leur équipe, les étudiants doivent s'autoformer (un minimum) sur les outils de développement présentés en cours.
  • 6 séances de suivi sont effectués par les enseignants tuteurs. Elles durent 2h avec le tuteur, suivi de 2h en autonomie pour avancer dans le projet, mais un travail personnel important, en dehors de ces 4h hebdomadaires, est attendu. Les séances de suvi permettent notamment de :
    • décomposer le travail entre les membres de l'équipe
    • surveiller l'avancement
    • aider les étudiants dans leur choix de conception
    • aider les étudiants sur des points techniques particuliers
  • Une soutenance du projet aura lieu une semaine environ après la fin des TD de suivi.

Calendrier

  • vendredi 6 février 2009 : publication des sujets
  • mardi 17 février 2009 : 1er cours
  • jeudi 19 février 2009 : date limite de retour des choix des étudiants, par équipe
  • lundi 2 mars 2009 : publication des affectations
  • jeudi 19 mars 2009 : 1er TD de suivi
  • jeudi 23 avril 2009 : dernier TD de suivi
  • 4 mai 2009 : soutenance

Sujet C : Système de classification de caractères manuscrits

Encadrement : Gilles Menez.

Il s'agit de réaliser un système de classification de caractères manuscrits conforme par exemple à celui qu'utilise la poste pour reconnaitre automatiquement les codes postaux.

Fonctionnalités attendues / déroulement :

  • Intégrer une base de connaissance de caractères,
  • Mettre en place une classification ... bayesienne par exemple,
  • Expérimenter sur des caractères issus de la base de connaissance,
  • Développer une plateforme graphique de test permettant de dessiner le caractère à reconnaitre.

Fonctionnalités complémentaires :

Si le temps le permet, gestion de méthodes alternatives et performances associées.

Equipes :

  • (c1a) ATOUI Mohamed Amine, CHAMPALBERT Julien, CORNU Pierrick, NICOLAS Sylvain
  • (c1b) DUCOT Vincent, LIU Zhaolong, ROL Elsa, MANNAI Heykel

Pour démarrer sans se tromper :

Sujet Java 1 : Réalisation de corpus par lecture de page web

Encadrement : Michel Gautero, Carine Fédèle.

Il s'agit de permettre la récupération des "divisions" (marqueurs div par exemple) d'une page web, et d'en permettre la sélection et la classification par l'utilisateur.

Fonctionnalités attendues / déroulement :

  • Récupération d'une page web à partir de son url
  • Récupération des "parties" de la page
  • Affichage du texte et des attributs liés à ces divisions.
  • Sauvegarde des "divisions" sélectionnées par l'utilisateur
  • Parcours et édition des informations recueillies
  • Interface graphique

Spécificités techniques :

  • Eclipse / Java / JUnit
  • API HTML Parser
  • API SqliteJDBC?

Equipes :

  • (java1a) Elzbieta Tataruch, Pelny Peya, Anthony Jacquemin, Mathias Kowalski
  • (java1b) Seck Maimuna, Texiera Tiago, Guigiero Michael, Buzatu Mihai
  • (java1c) Albertini Ken, Bruno Damien, Bu Gannam Suzan, Laville julien
  • (java1d) Arnhart Govinda, Briançon-Marjollet Nancy, Nourdine Mohamed Ali, Trillard Marc

Pour démarrer sans se tromper :

  • s'intéresser au fonctionnement de l'API HTML Parser et incrémentalement récupérer une page web, la liste structurée de ses divisions (div), les arguments de ces divisions, le texte associé à chacune d'elle.
  • Réfléchir à la structure de la base de données afin de pouvoir stocker pour chaque url, la ou les div voulues, le texte associé à ces div, les arguments de la div, la date de récupération.
  • s'intéresser au fonctionnement de l'API SQLiteJDBC? et incrémentalement voir comment stocker et récupérer les informations dans la base définie.
  • Développer séparément la partie Web et la partie SGBD en se mettant d'accord sur une interface de communication.
  • Enfin se pencher sur l'interface.

Sujet Java 2 : Simulateur de trafic urbain

Encadrement : Philippe Collet.

Il s'agit de réaliser un logiciel pour simuler le trafic dans le quartier d'une ville.

Fonctionnalités attendues / déroulement :

  • Configuration de la simulation : rues, croisements, nombre de voies, véhicules, vitesse, absence de collision, probabilité d'accidents aux croisements (tous ces éléments de la simulation peuvent être intégrés incrémentalement à partir d'un moteur de simulation simpliste de départ).
  • Les éléments de configuration de la simulation seront placés dans des fichiers, puis analysés et interprétés par le simulateur.
  • Lanceur de simulation graphique : chaque élément est de taille fixe (petit cercle ou petite image) sur une carte tenant entièrement sur l'écran.
  • Chaque véhicule a un but (un point de sortie du quartier ou un parking) et détermine dynamiquement à chaque croisement comment se rapprocher de ce but.

Fonctionnalités complémentaires (ordre non significatif) :

  • Editeur de terrain avec test de cohérence du graphe des rues.
  • Modification dynamique de la simulation (insertion/suppression de travaux, de véhicules)
  • Elément de simulation plus complexe : batiment spécifique servant de but (bureau, stade...), aller-retour d'un batiment a un autre pour certain véhicule (pompier)...

Spécificités techniques :

  • Eclipse / Java / JUnit
  • API Swing pour la partie graphique

Equipes :

  • (java2a) Kevin Ballestrazzi, Olivier Felt, Pierrick Martino, Grégoire Polidori
  • (java2b) Elodie Feugier, Laura Vikor, Yohann Lucas, Adrien Mussano
  • (java2c) Thomas GRAVINA, Guilhem BELLION, Christophe DUC, Jonathan GOBBO
  • (java2d) Cyril Gaujous, Rémy Fossat, Vanessa Bezin, Anthony Nicoletti
  • (java2e) Arabat Said, Gaag Delphine, Liu Fenfei, Vermeil Anne-Laure

Pour démarrer sans se tromper :

  • ne pas faire de moteur graphique (surtout si vous n'avez aucune expérience en Java sur cet aspect, attendez le premier TD)
  • développer TRES incrémentalement le noyau de la simulation (rue, voie, vehicule, croisement) : commencez pas concevoir et implémenter une rue avec une voie, placez (par programme) un véhicule à un bout et faites le aller à l'autre bout, puis dans l'autre sens, puis faites le tourner, faites un croisement, etc. Allez y très progressivement et conserver tous vos tests (normalement, vous ne savez pas encore comment les structurer avec Junit, l'essentiel est que vous conserviez le code de vos tests successifs, n'écrasez pas le main ou les méthodes à chaque fois que vous progressez !)
  • ne pas faire l'analyseur de fichier de configuration de simulation tant que le noyau de la simulation n'est pas stabilisé (sinon vous allez le réécrire 10 fois pour refléter les changements de fonctionnement de votre simulateur). Testez votre simulation par des sorties texte (vive System.out.println, pour l'instant...) et créer vos petits espaces de simulation par programme (créez une rue, un véhicule), plutôt que le faire lire dans un fichier.

Un exemple de simulateur avec séparation du moteur de simulation et du moteur graphique d'affichage:

Sujet PHP/MySQL 1 : Partage et suivi de document

Encadrement : Philippe Renevier.

Il s'agit de faire une plate-forme web permettant de réaliser le partage et le suivi de document. Il sera possible de déposer des fichiers et de demander des actions à d'autres personnes.

Fonctionnalités attendues / déroulement :

  • Déposer (upload) des fichiers, gérer des fichiers déposés
  • Proposer une gestion de version (ne pas écraser systématiquement un fichier que l'on redépose)
  • Fournir un accès (liens) aux fichiers, gérer la période d'accès autorisés à ces fichiers, gestion des accès publiques / "privés"
  • Permettre d'assigner des actions aux personnes. Gérer une description sémantique (mots clefs) des compétences et des rôles (fonctions) des personnes. Gérer une liste de personne.
  • Gérer automatiquement le déroulement des actions (rappel, délai, accès limité dans le temps)
  • Proposer des actions de base : relecture et correction (déposer une nouvelle version du document), relecture et avis motivés (déposer un avis motivé à propos du document), écriture de document à partir de ressources déposer (réaliser un document à partir de sources données).

Fonctionnalités complémentaires :

  • Définir des actions. Les actions seront définies par les fonctions utilisées (dépôt d'un ou plusieurs fichiers, plage temporelle pour déposer des fichiers)
  • Proposer une page de partage et d'échange par action (style tribune, forum)
  • Proposer des actions définies comme des suites d'actions.

Equipes :

  • (php1a) Saad AISSA, Sami Ben mosbah, Gabrielle Minetto, Salaheddine Mouafik
  • (php1b) PARISI Cédric, BENIGNO Nicolas, BENTCHIKOU Manyl, UNGAR Didier
  • (php1c) COLIN Yann, MASSIERA Julien, TAMAGNO Olivier, El Mazouzi
  • (php1d) MAHAMDEH Sally, N'Dao Oumar, Bennali Fellague Mohamed, Sitti Mohamed

Pour commencer :

  • il semble plus simple de viser la gestion des fichiers (stockage) et leurs publications (liens), cette publication étant organisée par dépôt.
  • De même, il faudra résoudre la gestion de version et de faire les pages utiles à la consultation.
Ensuite, il faudra itérer pour atteindre les fonctionnalités visées. Pour chacune des étapes suivantes, il conviendra de tester le bon fonctionnement des pages (ou script) :
  • Définition minimales (nom, adresse électronique) des personnes et ne faire qu'une action de base ("relecture et correction" par exemple) et l'assignation document / "relecture et correction". Faire les pages de gestions des personnes.
  • Etendre les profils des personnes pour associer aux personnes des mots-clés de compétences (choix parmi n mots-clés puis mots-clés libre). Filtrer (optionnel) les personnes en fonction des mots-clés pour l'affectation. Refaire la même chose avec les rôles (rédacteurs, etc.)
  • Faire la gestion automatique du déroulement de l'action "relecture et correction" (rappel, page pour le relecteur adaptée à ce qu'il est supposé faire, i.e. déposer un fichier). Attention, ce problème n'est pas simple (et il faudra peut-être passer un script qu'il doit supporter les arrêts).
  • Etendre aux 2 autres actions de bases.
  • Faire les pages de discussion par "dépôt" initial (qui lance une ou plusieurs actions).
  • Permettre d'enchainer les actions (par exemple d'abord relecture et correction par quelqu'un, puis relecture et avis motivé par une autre personne)
  • Finalement permettre la définition d'action.

Sujet PHP/MySQL 2 : Calendrier lieu d'interaction

Encadrement : Philippe Renevier.

L'objectif est de réaliser un calendrier qui centralise les activités de l'utilisateur, concentrant agenda, signets journaliers, et toutes activités ayant une date buttoir.

Fonctionnalités attendues / déroulement :

  • Réaliser un calendrier dont le contenu (chaque jour) est personnalisable et possédant plusieurs vue (année / mois / semaine / jour)
  • Réaliser un agenda qui s'insère dans ce calendrier (événements ponctuels, événements répétés, période, rappel par courriel)
  • Réaliser une gestion de signets (bookmark) de sites visités quotidiennement (ou hebdomadairement ou mensuellement) et qui permet de savoir ceux visités le jour même)
  • Intégrer des informations par jour, dont le placement pourra être soit en fond soit en texte "normal". Proposer un placement (simple) des informations les unes par rapport aux autres.
  • Gérer des informations pas toujours disponibles (comme la météo qui ne propose des prévisions qu'à quelques jours, bourses ou info valable uniquement le jour même)

Spécificités techniques :

  • Utilisation de web services (information disponible sur le web).

Equipes :

  • (php2a) Aurélie Casula, Sébastien Grasso, David Auk, Nassim Cherrak
  • (php2b) Alagbe Landry, Coulibaly Oumar, Safou Turpain, DIEYE Papa Yatma
  • (php2c) KABA Fanta Ibrahima, DIALLO Thierno Mamadou, KANN Amadou Tidia, Wardi Anwar
  • (php2d) Adeline Lefevre, Kitar Soumaya, Guillaume Benlahoussine, Thomas Strangi

Pour démarrer sans se tromper :

  • Il est conseillé de commencer par faire un calendrier (plusieurs vues), dont le contenu est facilement modifiable (utilisation d'interface d'objet et le paramétrage en php). Proposez des contenus simples, comme un flux rss d'information filtré par date (sur le jour même ou la veille) ou comme la récupération d'un petit article par jour
  • Attention, ces exemples couvrent des cas particuliers : soit l'information n'existe pas dans le futur, soit elle n'existe plus dans le passé, soit elle n'est pas continue (il n'y en a pas tous les jours). Ne pas se perdre dans une analyse de page web pour en extraire les données. Si une source est trop compliquée, prenez-en une autre.
  • Une fois ceci fait, vous pouvez faire la gestion de signets en commençant avec une liste de sites fixe, puis en proposant la personnalisation des signets et de la fréquence des visites.
  • L'étape suivante est de généraliser ce principe de personnalisation en gérant les informations à afficher dans le calendrier dans des pages de configurations (par exemple : avoir le choix de ne pas voir les événements "jusqu'au" de l'agenda de Nice).
  • La suite sera alors de permettre de voir plusieurs informations par jour, définir sur quelle vue elles sont visibles (vue jour / semaine / mois / année...) et avec quelle rendu (rendu simplifié pour les vues mois/années).
  • Finalement, proposez une solution de placement des informations.

-- PhilippeCollet - 09 Apr 2009
to top

I Attachment sort Action Size Date Who Comment
ProjetDevt-1-0809.pdf manage 610.7 K 12 Mar 2009 - 17:08 PhilippeCollet  
ProjetDevt-2-0809.pdf manage 549.8 K 12 Mar 2009 - 17:11 PhilippeCollet  
ProjetDevt-3-0809.pdf manage 892.1 K 19 Mar 2009 - 10:18 PhilippeCollet  
ProjetDevt-4-0809.pdf manage 233.3 K 24 Mar 2009 - 17:26 PhilippeCollet  
ProjetDevt-5-0809.pdf manage 253.3 K 31 Mar 2009 - 07:34 PhilippeCollet  
ProjetDevt-6-0809.pdf manage 189.0 K 03 Apr 2009 - 15:45 PhilippeCollet  
exemple-simulateurGraphique.zip manage 8.5 K 09 Apr 2009 - 11:30 PhilippeCollet  

You are here: Linfo > ProjetDevt2009

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WIKIDeptinfo? Send feedback