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 :
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 :
- 13h30 :
- 14h00 :
- 14h30 :
- 15h00 : pause
- 15h15 : e07
- 15h45 : e09
- 16h15 :
- 16h45 : pause
- 17h00 :
- 17h30 :
- 18h00 :