Skip to topic | Skip to bottom
Home
Linfo
Linfo.SoutenanceProjetLicence201314r1.4 - 15 May 2014 - 09:14 - PhilippeReneviertopic end

Start of topic | Skip to actions

Déroulement

Lieu : PV 301

Horaire : jeudi 5 juin, à partir de 08h00

Ordre de passage (toutes les 1/2 heures) :

  • 08h00 LTIPLITRA : Vivien Etienne, Arifa Karim, Elsenberger Kevin, Papasergio Anthony
  • 08h30 LTIPLITRB : AFSHARI Dariush, FASSINA-MOSCHINI Robin, LOZACH Maxime, PALMERO Romain
  • 09h00 LTIPLITRC : Mannocci Adrien, Nait Ouslimane Sofiane, Allena Johann, Dravet Jean-Baptiste
  • 09h30 LTIPLITRD : Pierre Christensen, Camille Yacoub, Yassine Youssef, Sergio Baudino, ILUNGA-KATUMBA Joël (équipe à 5)
  • 10h00 LTIPLITRE : Balde Thierno Mamadou Cellou, Berlioz Alison, Diallo Hassatou, Bezeid Moulayeely, DIENE MOUSSA (équipe à 5)
  • 10h30 PAUSE
  • 10h45 LTIPLITRF : Boutin Yoann, Benzarti Zied, Destefanis Marc, Varandas Kévin
  • 11h15 LTIPLITRG : SARROCHE Nicolas, FAGUET Guillaume, BELHASSEN Issam, FEZAI Ahmed
  • 11h45 LTIPLITRH : Ali Eskandari
  • 12h15 LTIPLITRI : Baya Aymen

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, et de la dernière version testable et exécutable sur le git (TIP 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 importantes :

  • dimanche 1er juin 23h59: arrêt du développement (site de gestion du projet et des sources)
  • mercredi 4 juin 23h59 : les transparents (pdf, open-office ou powerpoint 2010 PC) et le rapport sont à mettre dans le git dans un dossier "doc".

Consignes :

  • Chaque ticket fermé devrait idéalement correspondre à une version sur le git(ALERT! faites par exemple apparaître le numéro de version dans le texte associé au ticket)
Le git :
  • Tout le code doit être documenté raisonnablement : 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)

Le rapport contient les informations suivantes :

  • une description du contenu du git : branche, tag, les versions et ce à quoi cela correspond.
  • ALERT! Précisez vos pseudos de commit git, notamment si une personne a plusieurs "noms"...
  • les outils de développement utilisés (eclipse / android studio) et comment (re)faire un projet à partir de votre code. Et ce, pour la ou les partie(s) Android et pour l'éventuelle partie Serveur.
  • ALERT! comment compiler, déployer, exécuter la ou les partie(s) Android et l'éventuelle partie serveur.
    • ALERT! Si vous avez un serveur, vous devez nous fournir un serveur opérationnel sur lequel on puisse se connecter (en cas de problème de déploiement / exécution) : le serveur doit être opérationnel du lundi 2 juin 8h au vendredi 6 juin 20h.
    • ALERT! Dans tous les cas, décrivez bien les dépendances (bibliothèques, etc.) et les paramétrages (ouverture de port, etc.).
  • Synthétiser les grands choix de conception, les fonctionnalités livrées, les problèmes rencontrés, etc.
  • Jalons (Version) 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...)
  • Les réunions doivent aussi faire l'objet d'un compte-rendu (ticket réunion spécifique), que ce soit pour une réunion avec prise de décision au sein du groupe ou avec l'encadrant.
  • l'organisation et la couverture des tests.
  • une conclusion faisant le bilan du projet

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, modification du planning suite au changement demandé à mi-parcours,...)
    • Possibilité de mini-démo finale ou d'utilisation en continue de l'application (mais attention au timing)
    • ALERT! la création d'un compte autres actions "bateaux" ne doivent pas être présentés !
  • 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.

-- PhilippeCollet - 15 May 2014
to top


You are here: Linfo > SoutenanceProjetLicence201314

to top

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