U.E. Projets avancés en réseaux - advanced networking projects

RSX 218

Anciennement RSX207 au Cnam Paris et certains CRA

Les sujets 2019/2020 seront publiés en décembre 2019

Responsable d'UE : Stefano Secci (stefano.secci@lecnam.net)

L'objectif de l'U.E. RSX 218 est de mener des projets avancés en réseau, en montant en compétence sur des architectures et technologies qui soit ont été récemment adoptées dans les architectures de réseau-système (réseau d’entreprise, d’opérateur, de data-center, personnel ou déployables), soit sont dans un état de pré-production au niveau industriel.

Les projets proposés consistent principalement en la conception et l'expérimentation d'une application logicielle de réseau, d'émulation d'une configuration de réseau avancé et réaliste, de mise en place d'une plateforme réseau d'évaluation ou de test, généralement dans le cadre d'une activité d'enseignement, de recherche ou de développement plus importante. Ils sont l'occasion pour les participants d'acquérir une expérience de travail en équipe, de gestion de projets, de rédaction de rapports et d'exposé oral, et de monter en compétence sur des technologies d’avenir.

L'U.E. RSX218 est créditée de 6 ECTS, ce qui correspond donc à 150h d'investissement personnel par personne (temps en classe et travail personnel). Les sujets proposés nécessitent un travail collaboratif (en binôme ou trinôme) sur un peu plus de 4 mois. Seulement pour des cas exceptionnels et justifiés les projets peuvent être individuels.

Chaque projet est encadré par un responsable et l'évaluation des participants est réalisée de manière individuelle par un jury.

Les participants doivent se constituer en groupes et contacter directement le responsable d'UE et le tuteur du projet qui les intéresse, en indiquant toutes les UE RSX et SMB déjà effectués par chacun. Le choix d'attribution du projet est à la discrétion de l'équipe pédagogique. Les projets ne peuvent pas être dupliqués.

Sujets traités :

Les projets peuvent porter sur les sujets suivants :

  • Virtualisation et réseaux logiciels : protocoles et architectures NFV (Network Functions Virtualisation), Cloud IaaS (Infrastructure as a Service), SDN (Software Defined Networking), leur orchestration, et plateformes.
  • IoT (Internet of Things) et systèmes embarqués, protocoles, systèmes, orchestration, et leur integration aux réseaux et au cloud.
  • Sécurité des réseaux : protocoles, détection d’anomalies, émulation d’attaques, évaluation de solutions de mitigation contre les attaques.
  • Réseaux sans fils et mobiles : WiFi et ses évolutions, réseaux cellulaires, réseaux de capteurs et protocoles.

Pré-réquis :
RSX 101.
RSX 102 ou RSX 103.
RSX 112 pour les projets en sécurité des réseaux.
RSX 116 pour les projets en réseaux sans fils et mobiles.
RSX 217/208 pour les projets en virtualisation et réseaux logiciels.

Calendrier 2019/2020:

    Hyperplanning

  • 13 février : cours d'introduction et présentation des projets.

  • 20 février : travail en groupe en salle de TP;
    • avant le 21 février : choix du projet, par email avec objet "[RSX218] choix projet #N", au responsable d'UE après confirmation de l'encandrant.
    • avant le 24 février 2019 : rémise par email au tuteur d'une première version du cahier de charge.
  • 27 février : travail en groupe en salle de TP.
    • avant le 1 mars 2019 : rémise par email au tuteur de la dernière version du cahier de charge.
  • 5 mars: présentation du cahier de charge, plan de developpement et Gannt (avec répartition des taches) pour chaque projet.
    10' de présentation par projet (divisés équitablement entre les participants) suivie de questions.

  • 12, 19, 26 mars : séances de travail en salle de TP
     réunion avec le tuteur pour bien délimiter l’analyse.

  • Avant le 30 mars : rémise du rapport intermédiaire au responsable d'UE.
    Le rapport intérmédiaire est structuré comme indiqué dans le template au fond de cette page.

  • 2, 23, 30 avril : soutenances à mi-parcours (examen oral à mi-parcours).
    30' de présentation par projet (divisés équitablement entre les participants) suivie de questions.
    Créneau de passage par projet comme indiqué dans le tableau ci-dessous.
    Conseils pour la préparation de la soutenance au fond de cette page.

  • 7, 14, 28 mai : séances de travail en salle de TP
    réunion avec le tuteur pour cadrer la mise en oeuvre.

  • 4 et 11 juin : soutenances finales.
    25 de présentation par projet avec démonstration (divisés équitablement entre les participants) suivie de questions.
    Créneau de passage par projet comme indiqué dans le tableau ci-dessous.

  • 25 juin: examen avec réponse à quelques questions sur votre projet et remise du rapport final (le tuteur et le responsable d'UE doivent avoir contrôlé ce rapport et la vidéo de demonstration).

Listes des projet 2018/2019:

Num. Titre

Tuteur

Personnes Réunions et soutenances
1 Découverte de la plateforme CORD (Central Office Rearchitected as a Datacenter) B. Maaz (Cnam)
  • Hamza KECHIR  
  • Diallo Ibrahima
  • BISSALA Massamba Alphonse

Réunion I: 28/3
Mi-parcours: 4/4
Réunion 2: 9/5
Finale: 20/6

Sujet (cliquez pour développer) :

Description générale : Parmi les différentes plate-formes qui font surface dans le domaine des réseaux de télécommunication pour la virtualisation des réseaux, le projet CORD (Central Office Rearchitected as a Datacenter) est un projet qui cherche à s'imposer comme plateforme pour les opérateurs de télécommunication. Les composantes principales sont OpenStack comme Virtual Infrastructure Manager, ONOS comme controleur et XOS comme orchestrateur réseau-système. Trois use-cases sont dévéloppés: M-CORD pour les réseaux cellulaires, avec notamment la virtualisation de l'EPC (Evolved Packet Core) et de la BBU (BaseBand Unit); R-CORD pour les réseaux de collecte résidentielle; E-CORD pour les réseaux d'entreprises. Dans ce projet, l'objectif est de découvrir M-CORD et de mettre en place des tests de bon fonctionnement de différentes fonctions de réseau virtualisées (VNFs).

Prérequis :

  • programmation linux, administration réseau-systeme;
  • adressage et routage IP;
  • expérience avec openstack fort appréciée.

Travail à réaliser : La dernière release de CORD, vient avec une quinzaines de VNFs open source. Les taches sont de :

  1. analyser l'état du développement de chaque VNF publiée, en identifiant les fonctionnalités manquantes ou défaillantes sur la base de la documentation existante, mailing lists, forum, etc.
  2. choisir 4 VNFs à tester parmi celles les plus complètes, avec prédilection pour le vEPC et le vBBU si possible.
  3. effectuer et documenter des tests de bon fonctionnement pour chaque VNF isolée dans OpenStack, avec des programmes/scripts de génération de trafic et d'analyse de trafic commuté
  4. effectuer un test avec la ou les VNFs intégrées et chainées dans M-CORD.

Liens complémentaires :

 

2 Comparaison entre VPP et OpenVSwitch J. Leguay (Huawei)
  • Xueying HUANG
  • ZANG JIEDONG Jiedong
  • WANG Yipeng
Réunion 1: 14/3
Mi-parcours: 18/4
Réunion 2: 23/5
Finale: 20/6
Sujet (cliquez pour développer) :

Description générale : parmi les commutateurs logiciels actuellement proposés dans le domaine de la 5G, deux sont ceux principalement utilisés aujourd'hui. OpenVSwitch, originellement développé par Nicira, et VPP (Vector Packet Processing), soutenu principalement par Cisco. L'objectif de ce projet et de les comparer qualitativement et quantitativement et de défendre un meilleur choix entre le deux.

Prérequis:

  • adressage et routage IP
  • programmation linux, administration réseau-systeme;
  • notions des architectures SDN et NFV (RSX208 préférable)

Travail à réaliser: Les taches sont de :

  1. effectuer une étude de comparaison qualitative entre OpenVSwitch et VPP, mettant en évidance les fonctionnalités offertes et les limitations. Ne pas utiliser de controleur SDN.
  2. mettre en place une première maquette avec une topologie d'au moins 4 commutateurs et 2 terminaux (par exemple client et serveur video VLC) et valider le bon fonctionnement.
  3. mesures les performances en terme de QoS avec le deux plateformes, en en particulier temps de trajet de bout en bout et gigue.
  4. ajouter des sources de trafic externe causant des pertes, et analyser les résultats avec un débit externe croissant.

Liens complémentaires:

  • VPP : https://fd.io/technology/
  • http://www.openvswitch.org

 

3 Emulation d'une attaque BGP contre une blockchain S. Secci (Cnam)
  • ...
.Mi-parcours: ...
Finale: ... ..
Sujet (cliquez pour développer) :

Description générale : chaque jour des attaques à l'architecture BGP sont découvert. Principalement il s'agit d'attaques d'usurpation de route. Certains attaques ont semble-t-il visé le réseau Bitcoin. L'objectif de ce projet est de simuler une attaque BGP à un réseau de crypto-monnaie émulé en démonstrant le succès, en parant d'une étude récente.

Prérequis :

  • Programmation Linux, dministration réseau-système.
  • Notions de sécurité (RSX112 préférable).
  • Notions de l'architecture BGP (RSX208 préférable).

Travail à réaliser :

  • Etudier l'état de l'art et déterminer au moins trois topologies BGP à utiliser pour l'émulation de l'attaque, en réutilisant au moins une topologie déjà documentée et en définissant au moins une topologie pas documentée.
  • Mettre en place la topologie en utilisant GNS3.
  • Déployer un réseau bitcoin ou ethereum en exploitant le code disponible en ligne.
  • Emuler l'attaque avec les différentes configurations identifiées.

Liens complémentaires :

4 Découverte de la plateforme ONAP J. Sanchez (Orange)
  • Irajasingham CHUMARAN
    Christophe DUBUISSON
    Mehdi BOURMADA
Réunion 1: 21/3
Mi-parcours: 25/4
Réunion 2: 23/5
Finale: 20/6
Sujet (cliquez pour développer) :

Description générale : Open Network Automation Platform (ONAP) est une plateforme d’orchestration et de contrôle de l’environnement Software Defined Networking (SDN) / Network Function Virtualisation (NVF). Cette plateforme permet aux opérateurs d’optimiser et automatiser le déploiement d’infrastructure réseau. La première version, Release 1.0.0 Amsterdam, a été publiée en Novembre 2017. L’objectif de ce projet est de mettre en place une plateforme ONAP et effectuer des tests de fonctionnement et de services.

Prérequis :

  • Programmation Linux, Administration réseau-système
  • Notions des architectures SDN et NFV (RSX208 préférable)

Travail à réaliser :

  • Faire une recherche bibliographique en se basant sur les informations disponibles sur le site web d’ONAP, forum, mailing-list, etc. pour comprendre l’architecture d’ONAP et son état de développement.  
  • Télécharger la version 1.0.0 Amsterdam et suivre les instructions pour installer une plateforme ONAP.
  • Effectuer les tests fonctionnels et réaliser une démonstration de la plateforme

Liens complémentaires :

 

5 Découverte de la plateforme Kubernetes J. Sanchez (Orange)
  • Benjamin LYPHOUDT
  • Florian LECLERC
Réunion 1: 21/3
Mi-parcours: 25/4
Réunion 2: 23/5
Finale: 20/6
Sujet (cliquez pour développer) :

Description générale :
La « dockerization » des fonctions de réseau (VNF) est devenue une tendance de plus en plus suivie pour implémenter les services basés sur NFV, principalement en raison des bonnes performances en temps réel de ces architectures de virtualisation. Kubernetes est une telle architecture poussée par un grand nombre d'industriels.
L’objectif de ce projet est de mettre en place une plateforme Kubernetes et d'effectuer des tests de fonctionnement des services disponibiles des des VNF implémentés sous forme de containers.

Prérequis :

  • Programmation Linux, Administration réseau-système
  • Connaissances de python
  • Notions des architectures SDN et NFV (RSX208 préférable)

Travail à réaliser :

  • Faire une recherche bibliographique en se basant sur les informations disponibles sur le site web de Kubernetes, forum, mailing-list, etc. pour comprendre l’architecture de Kubernetes et son état de développement.  
  • Télécharger la version  v1.12 et suivre les instructions pour installer une plateforme Kubernetes.
  • Réaliser une démonstration de la plateforme Kubernetes avec un service de streaming vidéo.

Liens complémentaires :

 

6 Gestion de la QoS avec DASH et SDN B. Maaz (Cnam)
  • Mamadou Barry
  • Ahmed Ouerchefani
  • Brice Tchoulague
Réunion I: 28/3
Mi-parcours: 4/4
Réunion 2: 9/5
Finale: 20/6
Sujet (cliquez pour développer) :

Description générale: Le MPEG-DASH est un standard de format de diffusion audiovisuelle sur Internet. Il se base sur le principe d'adaptation de débit variable sur HTTP. Le contenu est découpé en des segments de courte durée de qualité et débit variable. D'autre part, le réseau défini par logiciel (SDN) est une architecture de réseau, qui permet la détermination des itinéraires de flux de paquets par un contrôleur externe. L'objectif de ce projet est d'implémenter une maquette sur SDN permettant de maximiser la QoS d'un réseau de diffusion DASH, en se basant sur la sélection dynamique des chemins d'un réseau SDN. Les auditeurs peuvent se baser sur une étude déjà publiée en références. La plateforme SDN sera implémentée en se basant sur l'émulateur MININET avec un contrôleur SDN et un Open Flow Manager (OFD) à choisir. 

Prérequis:

  • programmation Linux, administration réseau-système ;   
  • notions des architectures SDN (RSX208 préférable) ; 
  • adressage IP, HTTP, XML.

Travail à réaliser : 

  • étude del'état de l'art sur la QoS de MPEG-DASH dans les réseaux SDN.  ; 
  • mise en place d'une première maquette MININET avec une topologie d'au moins 4 commutateurs et 4 terminaux (1 serveur http, un serveur vidéo MPEG-DASH) et deux clients, avec un contrôleur SDN externe à choisir ; 
  • utilisation de Wireshark pour visualiser le trafic Open flow, avec interprétation des résultats ; 
  • tests de méthodes de sélection des chemins dynamique pour les flux DASH dans le but de l'amélioration des QoS ;
  • démonstration de la maquette obtenue et interprétation des indicateurs (debits, delai,..) de QoS obtenus.

Liens complémentaires: 



7 Migration de machines virtuelles avec continuité de service P. Raad
(T-Systems)
  • SIDIBE Mamoutou
  • HAMMOUCHE Mohand
  • L'HARIDON Stéphane
Réunion 1: 21/3
Mi-parcours: 4/4
Réunion 2: 9/5
Finale: .6/6
Sujet (cliquez pour développer) :

Description générale: avec l'émergence de la virtualisation, la problématique de migrer dynamiquement des machines virtuelles (VMs)entre des data-centers a été adressé. Historiquement, les premières solutions prolongeaient la signalisation ARP (Address Resolution Protocol) via des tunnels entre les data-center, en prévoyant donc le readdressage IP de VMs. Plus tard, des solutions basés sur LISP (Locator/Identifier Separation Protocol) on été étudiées et intégré dans des produits commerciaux, notamment par Cisco. D'autres protocoles de cloud network overlay résoudent également ce problème d'une façon similaire, comme notamment VXLAN (Virtual eXtensible LAN). Très recemment, Cisco a proposé d'utiliser le routage par segment avec une politique de redistribution de trafic, en montrant qu'on peut attendre séro pertes, toutefois sans avoir clairement qualifié l'impact du désordonnacement et de la multiplication des paquets dans l'application, en utilisant VPP (Vector Packet Processor). Ce projet vise à comparer les différenes approches avec des métriques applicatives et de qualité de l'expérience.

Prérequis:

  • programmation réseau avancée ; 
  • programmation linux, administration réseau-systeme;
  • connaissance des protocoles de cloud network overlay (RSX208 apprécié).

Travail à réaliser : 

  • faire un état de l'art et une comparaison qualitative;
  • identifier des applications temps-réel et de transfert de fichiers à utiliser;
  • identifier au moins 4 métriques applicatives et de qualité de l'expérience à mésurer;
  • monter une maquette commune aux différents projets;
  • comparer expérimentallement les approches ARP, LISP, VXLAN, VPP.

Liens complémentaires: 

8 Demonstration de vulnerabilités du SDN J. Sanchez (Orange)
Mi-parcours: ...
Finale: ...
Sujet (cliquez pour développer) :

Description générale: différentes attaques peu intuitives ont été récemment découvertes pour l'architecture, agissant au niveau de certains protocoles ou défauts de conception de l'architecture réseau. Elles sont décrites dans l'article ci-dessous. L'objectif de ce projet est de demonstrer ces attaques pour ONOS et pour ODL..

Prérequis:

  • programmation réseau avancée ; 
  • programmation linux, administration réseau-systeme;
  • connaissance des protocoles de cloud network overlay (RSX208 apprécié).

Travail à réaliser : 

  • faire un état de l'art sur la sécurité SDN et décrire de façon beacoup plus approfondie que dans l'article les attaques, avec aussi des exemples;
  • monter une maquette commune aux deux controleurs;
  • démonstrer experimentalement et documenter avec des vidéos de démo les attaques.

Liens complémentaires: 

9 Découverte et analyse du protocole QUIC J. Leguay (Huawei)
Mi-parcours: ...
Finale: ...
Sujet (cliquez pour développer) :

Description générale: Le protocole QUIC (Quick UDP Internet Connections) est un nouveau protocole de couche transport (4) initiallement conçu, implementé et déployé par Google en 2012, et annoncé publiquement en 2013. L'objectif de QUIC est de mieux répondre aux besoin en termes de qualité de l'expérience des applications web, en améliorant les performances qu'on peut obtenir avec TCP (Transport Control Protocol). Il a été intégré à Chrome et Chromium et prend aujourd'hui une proportion importante du trafic Internet. L'objectif de ce projet est de comparer différentes implémentations du protocoles et de déterminer la meilleure en termes qualité de l'expérience.

Prérequis:

  • Architecture TCP/IP et controle de congestion avec TCP.
  • programmation unix.

Travail à réaliser : 

  • Effectuer un état de l'art détaillé sur QUIC, son évolution et ses implémentations.
  • Effectuer un état de l'art sur la mésure de la qualité de l'expérience web.
  • Choisir 4 implémentations de QUIC parmi celles existantes et les comparer en fonction de métriques de qualité de l'expérience à choisir et défendre.
  • Démonstrer expérimentalement la quelle de ces implémentations est la meilleure.

Liens complémentaires: 



10 Démonstration de vulnerabilités d'OpenStack P. Raad
(T-Systems)
  • Flavien JOLY POTTUZ
  • Gaël LE BRETON
Réunion 1: 21/3
Mi-parcours: 4/4
Réunion 2: 9/5
Finale: .6/6
Sujet (cliquez pour développer) :

Description générale: OpenStack devient la plateforme de référence pour la gestions de machines virtuelles ou containers opération des infrastructures NFV. L'objectif de ce projet est de demonstrer un ensemble de vulnerabilités découvertes pour OpenStack depuis 2017.

Prérequis:

  • Architecture TCP/IP et controle de congestion avec TCP.
  • programmation unix.
  • connaissance des architectures NFV/SDN (RSX208 apprécié).

Travail à réaliser : 

  • Effectuer un état de l'art détaillé sur les plateformes NFV et l'usage de OpenStack pour ces environments.
  • Etudier et catégoriser les différentes vulnerabilités d'OpenStack découvertes depuis 2017.
  • Justifier le choix d'un sous-ensemble d'au moins 4 vulnerabilités les plus complexes et significatives à démontrer.
  • Démontrer les vulnerabilités, et leur éventuelle correction dans des versions successives.

Liens complémentaires: 



11 Détection d’anomalies dans les réseaux SDN J. Sanchez (Orange)
Mi-parcours: ...
Finale: ...
Sujet (cliquez pour développer) :

Description générale:
Ce projet porte sur la découverte d'outils nécessaires à implémenter des algorithmes de machine learning. L’objectif de ce projet est d'appliquer ces outils aux traces de plan de contrôle (OpenFlow) pour la détection d'anomalies de réseau SDN.
Les outils qui seront utilisés et comparés dans ce projet sont les suivants :
• libraires python : numpy, SciKit Learn, TensorFlow.
• Jupyter notebooks.

Prérequis:

  • Connaissance de python et/ou MATLAB et/ou Octave.
  • Notions de base machine learning et intelligence artificielle.
  • Notions de base architectures SDN (RSX208 préférable).

Travail à réaliser : 

  • Installer un notebook Jupyter dans un environnement Windows, et commencer à utiliser les libraries SciKit Learning, TensorFlow, numpy.
  • Créer des traces pcap issues du plan de controle et de transfert d’un réseau SDN de test à créer, en utilisant de flux applicatifs différents.
  • Extraire des caracteristiques (feature) du trafic capturé (par exemple, temps entre messages OpenFlow, taille du paquet, type de protocole, numéros des ports, etc).
  • Proposer une approche pour appliquer les outils de machine learning avec ces features et comparer les résultats obtenus avec chaque outil.

Liens complémentaires: 

12 Découverte de WiFi Direct J. Leguay (Huawei)
  • Gabriel TUDOR

Réunion 1: 14/3
Mi-parcours: 18/4
Réunion 2: 23/5
Finale: 20/6

Sujet (cliquez pour développer) :

Description générale : WiFi-Direct, appelé aussi Wifi Peer-to-Peer (P2P), est un mode de communication dans les réseaux 802.11 permettant à un groupe des terminaux WiFi de communiquer directement. Dans un groupe WiFi Direct, un terminal est élu comme Group Owner (GO) et joue le rôle du point d’accès pour fournir la connectivité aux autres membres du groupe. L’objectif de ce projet est de réaliser un test-bed de réseau Wi-Fi Direct, analyser  et comparer les performances avec celles d'un réseau WiFien mode infrastructure. Nous nous intéressons particulièrement au cas d’un GO qui joue le rôle d’un relai pour connecter un client ou plusieurs clients à un point d’accès qui est relié à l’Internet.

Prérequis :

  • Programmation Linux
  • Administration réseau-système
  • Programmation Android

Travail à réaliser :

  • Faire une recherche bibliographique sur le protocole WiFi-Direct   
  • Réaliser les communications Wi-Fi Direct avec des tablettes ou téléphones Android et analyser le protocole Wi-Fi Direct en utilisant Wireshark. 
  • Développer un programme sous Android permettant au GO de relayer les données entre un client et un point d’accès relié à l’Internet.
  • Mesurer les performances comme le temps d’établissement d’un groupe Wi-Fi Direct, la qualité de services des communications via un GO.
  • Comparer les performances d’une communication en mode infrastructure et d’une communication via un GO.




 

Rédaction et remise des documents :

Pour vos rapports, vous devez impérativement suivre les consignes de rédaction se trouvant dans les documents aux formats suivants :

La procédure de remise de vos documents consiste simplement à les envoyer via e-mail, avec le bon sujet et le bon nom de fichier (vous devez respecter impérativement les 3 points ci-dessous), au responsable d'UE.

  • Format obligatoire de l'unique fichier joint : PDF, non compressé, non archivé et de taille inférieure à 8 Moctets
  • Nom du fichier joint respectant la syntaxe suivante :
    • ProjetNumProj-NomEncad-NomCourtProjSansEspaces-RapInter.pdf (remplacer les parties en rouge)
    • ProjetNumProj-NomEncad-NomCourtProjSansEspaces-RapFinal.pdf (remplacer les parties en rouge)
  • Sujet de l'e-mail respectant la syntaxe suivante :
    • [RSX218] ProjetNumProj-RapInter (remplacer les parties en rouge)
    • [RSX218] ProjetNumProj-RapFinal (remplacer les parties en rouge)

Le non respect intégral de cette procédure invalidera la remise de votre document.

Conseils pour la soutenance mi-parcours et finale (présentation orale + questions) :

  • durée = 25 minutes pour un groupe de :
    • respect du temps imparti impératif (présentation intérrompue au dépassement du temps prévu)
    • tous les participants doivent intervenir à peu près le même temps sur des parties d'importance similaire pour le projet (afin que chacun puisse montrer sa compréhension de ce qui a été réalisé)
    • répéter plusieurs fois avant la présentation finale (pour vérifier la répartition des temps alloués à chacun)
  • faire une présentation vivante,
    • ne pas lire ses notes (et ne pas apprendre par coeur);
    • avoir un discours clair (phrases courtes) se rapportant à un fil conducteur;
    • parler en face de l'auditoire et montrer sur les transparents les points énnoncés.
  • forme des transparents simples :
    • style sobre (noir sur fond blanc idéal) ;
    • police sans-sérif, droite, fonte de taille suffisante (texte le plus petit en 18pt) ;
    • favoriser les figures pour les explications ;
    • pas de transitions annimées (pas d'animation sauf pour l'illustration dynamique d'un mécanisme) ;
    • pas de code ni de trace (sauf de courts extraits si nécessaire à la compréhension).
  • 10 à 15 transparents maximum. Exemple de plan :
    • présentation du sujet et des membres du groupe (1 transparent) ;
    • contexte technologique (1 à 2 transparents) ;
    • cahier des charges (1 transparent) ;
    • analyse (2 à 3 transparents) ;
    • développement réalisé en précisant les difficultés surmonté et les résultats obtenus (4-7 transparents) ;
    • bilan du projet (1 transparent).
  • en annexe, si vous vous attendez à certaines questions, vous pouvez prévoir des transparents complémentaires pour illustrer vos réponses.

Évaluation :

Pour chaque personne, la note finale de l'U.E. se situera entre 0 et 20.

La note finale est composée de la manière suivante

  • 5% Note du cahier de charge et sa présentation.
  • 15% Note de rapport intermédiaire et soutenance à mi parcours.
  • 20% Note de rapport final, démonstration et soutenance finale.
  • 30% Note du tuteur (qualité de la réalisation) - individualisée
  • 30% Note de jury - individualisée
web
analytics