User:PhilippeCollet > Projet de développement 2012-2013 > Soutenance de projet de développement L3 2012-2013

Soutenance de projet de développement L3 2012-2013

De $1

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 de la documentation sur la partie wiki de votre site Redmine, et 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, indiquez quelle numéro de revision il faut récupérer pour pouvoir évaluer votre code).

Rappel des dates limites :

  • Dimanche 5 mai 23h59 : arrêt du développement (site de gestion du projet et des sources)
  • Mardi 7 mai 6h00 : arrêt des modifications sur le site wiki pour expliquer le projet et préparer les infos de présentation : les transparents (
    pdf, open-office ou powerpoint) sont à mettre dans le redmine, dans "fichier"
  • Mardi 7 mai à partir de 8h30  : soutenance

Chaque projet doit rendre accessible les informations suivantes :

  • Redmine :
    • Wiki : au moins la page principale éditée pour synthétiser les grands choix de conception, les fonctionnalités livrées, les problèmes rencontrés, etc.
    • 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.
  • Subversion :
    • 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 (pour être justement exécutée et testée)

Déroulement et évaluation

Chaque soutenance dure 25 minutes :

  •   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:

  • Wiki: clarté et contenu  : 2 pts
  • Utilisation des outils de suivi (redmine, jalons, tickets, versions dans svn, commentaires) : 2,5 pts
  • Soutenance (explications, démo) : 2,5 pts
  • Réponses aux questions : 1,5 pts
  • Fonctionnalités réalisées / cahier des charges : 4,5 pts
  • Qualité du code (modularité, bonne utilisation du paradigme) et doc embarquée : 3 pts
  • Tests unitaires (pertinence, criticité, mise en oeuvre de tests dès le départ) : 4 pts
  • Exécution des tests et de l'application : coefficient multiplicateur (x1.05 si au dessus des attentes, x1 si conforme aux attentes, x0.75 si en dessous des attentes)

Calendrier

7 mai - TD 13

  • 8h30 : e10
  • 9h00 : e13
  • 9h30 : e15
  • 10h00 : e14
  • 10h30 : pause
  • 10h45 : e05
  • 11h15 : e07
  • 11h45 : e09
  • 12h15 : e11

7 mai - TD 14

  • 8h30 : e01
  • 9h00 : e02
  • 9h30 : e03
  • 10h00 : e04
  • 10h30 : pause
  • 10h45 : e06
  • 11h15 : e08
  • 11h45 : e12 
Mots clés:
 
Images (0)
 
Commentaires (0)
Vous devez être connecté pour poster un commentaire.