Skip to topic | Skip to bottom
Home
Linfo
Linfo.PageSoutenanceProjetInfo201314r1.4 - 19 Dec 2013 - 08:19 - PhilippeReneviertopic end

Start of topic | Skip to actions

Déroulement

Lieu : PV 301

Début : 08h00

Ordre de passage (toutes les 1/2 heures)

08h00 - Groupe H - MANNOCCI Adrien FAGUET Guillaume SARROCHE Nicolas DIENE MOUSSA LELLOUCH Willy

08h30 - Groupe G - NAIT OUSLIMANE Sofiane ALLENA Johann DRAVET Jean-baptiste

09h00 - Groupe F - BAUDINO Sergio CHRISTENSEN Pierre MOULAYEELY Bezeid YACOUB Camille

09h30 - Groupe E - Belhassen issam. Fezai ahmed, Youssef yassine. Baya aymen.

10h00 - Groupe D - ilunga katumba joel Hassatou Diallo Thierno Mamadou Cellou Baldé Berlioz Alison

10h30 - Groupe C - Etienne Vivien Elsenberger Kevin Papasergio Anthony Arifa Karim

11h00 - Groupe B - Kévin Varandas Yoann Boutin Zied Benzarti Marc Destefanis.

11h30 - Groupe A - PALMERO Romain LOZACH Maxime AFSHARI Darius FASSINA-MOSCHINI Robin.

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 :

  • mardi 17 décembre 2013 23h59: arrêt du développement (site de gestion du projet et des sources)
  • mercredi 18 décembre 2013 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 (pages et classes PHP) : 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)
  • Si une bd est utilisée : un export sql (avec des données à l'intérieur) et les paramètres par défaut de la connexion à la bd doit être soit dans le git soit dans un document facilement identifiable : il faut quel'on trouve toutes les informations d'installation et de configuration (y compris la bd)
Le rapport contient les informations suivantes :
  • 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, abandon d'une fonctionnalité...)
    • 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.

-- PhilippeRenevier - 12 Dec 2013
to top


You are here: Linfo > ProjetInfo201314 > PageSoutenanceProjetInfo201314

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