Fonctionnement du cours

Le Projet

Le projet IPI consiste à développer un jeu informatique original avec le langage python. Il utilisera une interface textuelle via un terminal de type Unix. Pour ce semestre de printemps 2022, nous imposons le thème “xxxx à définir xxxxx”.

Puisque pour la plupart d’entre vous, c’est la première fois que vous vous attaquerez à un programme informatique de cette envergure, vous aurez besoin d’éléments techniques et méthodologiques pour vous en sortir. C’est pour cela que le semestre comporte 2 phases :

• L’acquisition de savoirs faire nécessaires à la réalisation du projet
• La réalisation du projet

L’objet de cet ENIBOOK est de vous fournir les éléments de la première phase.

Ensuite, pour réaliser le projet, vous devrez exprimer et analyser le besoin d’un produit que vous devez imaginer. Ainsi, vous vous appuierez, en les améliorant au cours du projet, sur votre document de conception et votre cahier des charges. De plus, vous mettrez en œuvre une architecture de type « boucle de simulation » et vous appliquerez le principe de la barrière d’abstraction.

Vous réaliserez ce jeu sur votre machine personnelle et sur les machines de TP de l’ENIB. Le jeu devra être testé et fonctionner sur les machines de TP de l’ENIB.

Le projet peut être réalisé en binôme ou seul. Dans le cas du travail en binôme, les deux membres du binôme doivent avoir validé l’objectif boucle de simulation pour pouvoir démarrer le projet. Pour que le projet puisse être noté les membres du binôme doivent avoir validé les objectifs préalables dans les temps. S’il y a un décalage trop important dans les temps de validation des objectifs, le travail en binôme sera refusé.

Calendrier

Le semestre comporte 24 Unités de cours (36h) effectuées en tutorat ou autonomie.

• La période de préparation est estimée à 6 semaines:

  • 12 UC en salle classique

    • tutorat
    • évaluation
    • expression et analyse du besoin

• La période de développement est estimée à 6 semaines:

  • 12 UC en salle de TP

    • développement

**Le projet peut commencer à partir du moment où l’objetctif “boucle de simulation” est validée.

Le projet démarre au plus tard en début de P2, au retour de la première semaine de ZG. Autrement dit il faut absolument avoir validé l’objectif “boucle de simulation” en P1**

Il comporte 4 livrables:

• Cahier des charges (à rendre au plus tard avant la 2ième semaine de P2)
• Document de conception (à rendre au plus tard avant la 3ième semaine de P2)
• Prototype 1 ( code + documents à jour)
• Version finale ( code + documents à jour)

Les dates de rendu de ces livrables seront négociées avec l’enseignant et entérinées à la remise du cahier des charges.

Le principe du jeu décrit dans le cahier des charges doit être validé par votre enseignant avant de passer à la conception.

Les choix de conception doivent être validés par votre enseignant avant de passer à la phase de développement.

Un projet qui débuterait après le début de P2 ne sera pas noté.

Stratégie d’apprentissage.

Il vous est demandé de faire attention à la stratégie d’apprentissage que vous allez mettre en oeuvre au cours du semestre. En effet, s’il a pu vous être demandé par le passé de travailler par répétion ou apprentissage “par coeur”, le cours de IPI n’est pas compatible avec cette façon de faire. Nous cherchons à valider des compétences. Il ne s’agit donc pas d‘“apprendre le cours” mais d‘“apprendre à faire ce qui est décrit dans le cours”. Pour y arriver il vous appartient :

• de coder, de faire des erreurs, d’apprendre à corriger ces erreurs et de coder encore
• de comprendre le déroulé du cours, les objectifs visés et de vous positionner dans la progressions proposée.
• de soliciter votre enseignant car l’enibook n’est pas un MOOC et ne se suffit pas à lui même.

Si la difficulté technique reste limité en IPI par rapport aux autres matières de l’école, le travail proposé vous laisse une grande liberté. Il vous appartient de composer avec cette liberté, ce qui est difficile pour la plupart des élèves. Certains points d’évaluation porte sur le respect des consignes données à l’orale ou le respect d’éléments de méthodologie. Un minimum de maturité et de prise de recul est nécessaire pour éviter d’échouer. Comme dans la “vrai vie” d’un ingénieur, le projet IPI peut se solder par un échec.

Attention, une mauvaise méthode de travail peut conduire à une explosion du temps de travail personnel pour cette matière. N’hésitez pas à échanger avec votre enseignant en cas de difficulté.

Le système de notation a pour effet de focaliser l’attention de l’enseignant sur les élèves en difficulté. Profitez de cette attention pour progresser. Évaluation ———-

L’évaluation comporte deux parties:

1. validation du tutorat (6,5 points)
2. notation du projet (15,5 points)

La note finale maximale pourrait théoriquement être de 22/20.

2. Notation du projet.

• Il y a 4 objectifs qui correspondent à 4 livrables:

  • Expression et analyse du besoin
  • conception
  • développement et livraison du prototype intermédiaire
  • développement et livraison du projet final.

Les 4 livrables seront envoyés par e-mail à votre enseignant, au plus tard à la date définie dans le cahier des charges. Les livrables du prototype intermédiaire et final contiendront le code et les PDF des documents de conception et de cahier des charges. Le tout sera envoyé sous forme d’archive au format ZIP ou TGZ au dates établies dans le cahier des charges. Les archives seront bien structurée et bien nommée. Le suivi du projet se fera en mettant à jour le document de conception. Chaque livrable fournira les différentes versions du document de conception.

Les livrables seront remis par e-mail à votre enseignant qui vous délivrera un accusé de réception. Ne considérez le travail livré que lorsque vous recevez l’accusé de réception.

Les critères permettant de noter le projet sont les suivants :

• respect des contraintes et des méthodes de codages décrites en cours
• technicité
• quantité de travail fourni
• cohérence
• originalité
• jouabilité
• respect des délais
• robustesse

** Un projet qui ne s’exécute pas ne pourra permettre une note de IPI supérieure à la moyenne; ce qui correspond à une note < 5,5/15,5 pour le projet. **

** Un projet moyen obtiendra une note de 5,5/15,5 qui permettra d’obtenir une note moyenne de 12/20 en IPI si tous les objectifs ont étés validés. **

** Si le codage du projet ne démarre pas première semaine de P1, le projet ne sera pas noté. la note de IPI sera donc <7/20. ** L’idée derrière cela est que vous passiez nécessairement 4 semaines à coder en laboratoire. Dans le cas contraire il est impossible d’évaluer la qualité de votre travail. L’enseignant évalue votre travail ET la façon dont vous travaillez; il doit donc vous voir pendant les séances de TP.

La figure ci-dessus indique quels sont les prérequis pour valider un objectif. Celle ci-dessous les dates auxquelles vous devez passer les objectifs.

Travail en binôme

Pour imposer un réel travail en équipe (si le projet est réalisé en binôme), des points de malus pourront être infligés à l’évaluation du projets dans les cas suivants :

• si au cours des séances un développeur ne semble pas comprendre comment fonctionne le code développé et ne peut expliquer l’architecture du projet.
• si un développeur fait preuve d’absentéisme.

Les deux membres du binôme doivent avoir validé le tutorat pour pouvoir démarrer le projet. Pour que le projet puisse être noté les membres du binôme doivent avoir validé les objectifs préalables dans les temps. S’il y a un décalage trop important dans les temps de validation des objectifs, le travail en binôme sera refusé.

Fraude

L’utilisation de code produit par un tiers est permise. Vous pouvez donc importer dans votre projet du code produit par d’autres, si vous en avez l’autorisation. Par exemple, il est acceptable d’utiliser un module fourni par un autre binôme si vous le signalez clairement dans le document de conception. On parle ici de l’importation de module complet. Bien sûr, l’évaluation du projet prendra cela en considération.

Vous devez être les auteurs du code dont vous vous attribuez la paternité. Si vous intégrez du code plagié dans votre programme cela sera considéré comme de la fraude; surtout si vous ne maîtrisez pas parfaitement son fonctionnement.

Évidemment le partage de solution entre projet reste possible dans la mesure ou à la fin le code est bien écrit par un membre du projet.

(Attention, nous gardons les archives des projets des années précédentes...)