Soutenance de projet de développement L3 2013-2014

De $1

Version de 06:15, 18 Aoû 2024

cette version.

Revenir à liste des archives.

Voir la version actuelle

Modalités et calendrier des soutenances

Résultat attendu pour chaque projet

Le rendu du projet NE consiste PAS dans un packaging quelconque de sources ou de documentation. Il consiste en la mise à disposition d'un fichier README à la racine du référentiel git, ainsi de la dernière version compilable, testable et exécutable sur le subversion. Si cette dernière version stable n'est pas la dernière version commitée, placez un tag (git tag, ce n'est pas compliqué) et indiquez le dans le fichier README.

Rappel des dates limites :

  • Dimanche 11 mai 23h59 : arrêt du développement (le fichier README doit contenir au moins les explications de setup du projet pour test et exécution)
  • Lundi 12 mai 23h59 : arrêt des modifications sur le fichier README (le fichier README doit aussi contenir l'explication des grands choix de conception et une synthèse sur l'état du projet livré)
  • Mardi 13 mai à partir de 8h30  : soutenance

Chaque projet doit rendre accessible les informations suivantes :

  • JIRA :
    • Jalons (Version redmine) déterminés dans le projet (a priori ou a posteriori, l'essentiel étant de communiquer sur ces jalons)
    • Identification des tâches individuelles ou en binôme : ticket (tâches, bugs corrigés...)
    • Chaque ticket fermé devrait idéalement correspondre à une version sur le subversion (faites par exemple apparaitre le numéro de version dans le texte associé au ticket)
    • Les réunions doivent aussi faire l'objet d'un compte-rendu.
  • Git :
    • README (setup du projet + choix de conception + synthèse sur l'état du projet livré)
    • Tout le code doit être documenté raisonnablement (fichiers source en Java, packages compl) : entête du module/classe, commentaire sur les fonctions/opérations les plus importantes (pas forcément les getters/setters...)
    • De la même manière, les fonctionnalités les plus critiques doivent être forcément testées (plus une fonctionnalité est critique ou vous a posé de problèmes, plus on s'attend à la voir fortement testée). Etre capable de passer l'ensemble des tests écrits sur votre projet fait partie des résultats attendus (il doit donc y a voir de la documentation pour expliquer comment faire). De plus, il est aussi attendu que l'équipe puisse argumenter ses choix de test (pourquoi telle ou telle partie a été plus ou moins testée et comment).
    • Chaque commit devrait avoir un commentaire associé (ce commentaire n'a pas a être très long, surtout si la fermeture d'un ticket correspond au commit
    • La dernière version exécutable et testable doit être identifiée le jour de la soutenance (par défaut, la tête du master, sinon spécifiez le tag correspondant)

Déroulement et évaluation

Chaque soutenance dure 25 minutes (chaque équipe amène ses slides sur un portable qui peut se connecter à un vidéo-projecteur en VGA

  •   15 minutes de présentation : chaque présentation doit faire intervenir tous les membres de l'équipe de façon équivalente. Le plan suivant est conseillé :
    • Introduction et rappel du sujet
    • Fonctionnalités réalisées : bilan à gros grain de ce qui a été fait, est resté en chantier, a été écarté par rapport à ce qui était attendu (démo possible mais pas obligatoire)
    • Grands choix de conception et approche suivie : les jalons et tickets doivent vous servir à facilement établir, au fur et à mesure de votre avancement, les éléments à mettre en avant dans cette partie
    • Problèmes rencontrés et solutions apportées (correction, changement dans la conception, abandon d'une fonctionnalité...)
    • Possibilité de mini-démo finale ou d'utilisation en continue de l'application (mais attention au timing)
  • 10 minutes de question :
    • Chaque membre du projet doit être capable de répondre aux questions sur les choix de conception généraux, les parties qu'il a dévéloppées, etc.

Le barème utilisé se décompose comme suit:

  • Code livré : 40 % (fonctionnalités livrées, architecture, qualité et tests)
  • Gestion de projet : 25 % (utilisation des tickets, git, organisation, README)
  • Soutenance : 20 % (explications, démo éventuelle, réponses aux questions)
  • Avancement en TD : 15 % (présence, intervention dans le projet, mise en oeuvre des tests au plus tôt)

Calendrier

11 mai - salle TD 13

  • 13h00 : LTMPDTRA : Lea Dagnino, Rémi Allegro, Loric Beatini, Florian Champoussin (1)
  • 13h30 : LTMPDTRC: Cavallini Laurent, Puybonnieux Pierre, Nguyen Van Emilie, Gauche Nicolas (1)
  • 14h00 : LTMPDTRD: Carbonini Besson Benjamin, Giro Valerio, Massa Florian, Moise Yoann (1)
  • 14h30 : LTMPDTRF: Elmahdi KORFED, Kevin AUCHOYBUR, Wissam EL HADI, Mohamed NIANG (1)
  • 15h00 : pause
  • 15h15 : LTMPDTRG: Romain ABELLO, Maxime DEMETRIO, Tristan POILVET, Timoty TARTENSON (2)
  • 15h45 : LTMPDTRI: Charpentier Renaud, Jauvat Fabrice, Linares Thibaut, Excoffier Patrice (2)
  • 16h15 : LTMPDTRJ: AHMED SOILIHI Mouhaimine, N'DIAYE Birame, ALI KARI Zalbiya, HATTA Salaheddine (2)
  • 16h45 : pause
  • 17h00 : LTMPDTRB: Abdel BEDJBEDJ, Mohamed Rayane EL MOUSLIH, Mazen GHARBI, Julien PIATEK, Maxence CHAZARRA (3)
  • 17h30 : LTMPDTRE: Florent Comba, Aurore Dechamps, Kévin Garro, Samuel Waknine (3)
  • 18h00 : LTMPDTRH: CARON Anthony, REALE Benjamin, RAFIDISON Sandy, WALLART Sébastien (3)