Vous êtes ici : FIL > Portail > Master Informatique > M1S2 > PJI

PJI : Projet individuel

Responsable

Application de gestion des projets

Organisation

Le projet se déroule tout au long du second semestre, sans créneaux particuliers réservés dans l'emploi du temps. Cependant, au cours de ce semestre qui est principalement organisé sous la forme d'options, chaque étudiant aura de larges plages de liberté dans son emploi du temps. Lors de la diffusion des sujets, les étudiants doivent rapidement prendre contact avec les auteurs des projets qu'ils souhaitent réaliser. Les projets sont préférentiellement réalisés en binômes mais peuvent être faits seuls. Les alternants n'ont pas à suivre cette UE.

Il est fortement conseillé de travailler sur votre projet dès l'affectation de ce dernier car celui-ci représente 100h de travail effectif (et efficace) par étudiant. En effet, les 2 derniers mois de l'année (avec les rendus finaux de projets des autres matières, les contrôles de TD, les contrôles de TP et examens finaux), vous laisseront à peine le temps de réaliser votre rapport et préparer votre soutenance. Le travail doit donc être normalement quasiment terminé et validé fin avril. Pour celà, il est donc souhaitable de fixer (avec l'auteur du projet et/ou l'encadrant informatique) au minimum une réunion hebdomadaire durant le 1er mois du projet (cibler les objectifs, maitriser les technologies demandées), suivie d'un réunion au minimum tous les 15 jours pendant la phase de développement et de validation.

Crédits

5 ECTS


dernière modification : 31/08/2016 à 13:50:06

Dates à noter (année 2016-2017)

Lundi 28 Novembre 2016 :
ouverture de l'application de gestion des projets → les étudiants doivent contacter le/les auteur(s) du/des projet(s) souhaité(s), et doivent décider ensemble de l'affectation d'un projet donné. (l'auteur devra indiquer cette affectation par email au responsable des projets, ou directement via l'interface des projets: merci aux auteurs de faire cette affectation le plus rapidement possible).
Vendredi 13 Janvier 2017 :
fermeture de l'application de gestion des projets → fin de l'attribution des projets.
Lundi 06 Mars 2017 :
jalon intermédiaire (50%) (travail en cours, plan rapport + début rédaction (introduction))
→ à rendre sur PROF (10Mo max).
Mardi 02 Mai 2017 :
jalon "avant livrable" (90%) (travail très avancé + tests en cours, rédaction avancée)
→ à rendre sur PROF (10Mo max).
15 mai 2017 :
rendu du rapport final (voir rubrique Évaluation pour plus de détails).
lundi 22, mardi 23 et mercredi 24 mai :
soutenance et évaluation finale (voir planning de PJI-SDL).

dernière modification : 31/08/2016 à 13:41:46

L'évaluation du projet sera faite par :

  • des rendus intermédiaires effectués sur l'interface PROF (courant mars-avril),
  • un rapport (voir l'onglet Rapport)
  • une soutenance finale

Un seul rapport est rédigé par projet.

Une note sera attribuée à chaque étudiant, en fonction :

  • d'abord du travail réalisé, évalué par l'auteur et l'encadrant de projet,
  • ensuite de la soutenance et du rapport, évalués par le jury. Seront pris en compte :
    • la qualité du rapport proposé, de la soutenance réalisée,
    • la difficulté du travail demandé, et surtout le temps investi et l'implication de chaque étudiant dans le projet.
  • Il n'y a PAS de seconde session possible.

    La soutenance doit au plus durer 20 minutes (+ 5 min de questions + 5 minutes de délibération). Il vous est demandé d'avoir sur deux supports (au choix : clefs USB en Fat, disque amovible, autre) une version au format "pdf" de votre fichier de présentation (en plus de la version open-office éventuelle). Sauf avis contraire de l'auteur du sujet, les soutenances sont ouvertes aux autres étudiants/enseignants, dans la limite des places disponibles.

    Les soutenances ont lieu en salle de TP. Il faut donc avoir un compte actif au FIL (cela devrait être le cas…). Il n'est pas possible d'utiliser sa machine personnelle pour la présentation. Les présentations se font sur les ordinateurs présents en salle (vous les connaissez bien et pouvez tester auparavant ce qui fonctionne ou pas dessus).

    L'unité acquise apporte 5 ECTS.


    dernière modification : 31/08/2016 à 13:41:46

Le rapport demandé, du point de vue des exigences « contenu » et « forme » est à la discrétion de l'auteur et de l'encadrant. Le rapport est à priori à rédiger en français.

Page de titre

Le titre et le numéro de projet, ainsi que le nom des étudiants, auteur et encadrant, doivent au moins figurer sur la couverture.

Remise du rapport

Un exemplaire papier du rapport doit m'être transmis (Mikael Salson) avant la date limite (15 mai 2017). Il est possible de déposer les rapports dans mon casier du M3 (1er étage), il est également possible de me les donner en main propre le dernier jour (15 mai 2017) entre 16h et 18h (dernier délai) au bureau 204 du M3 (2eme étage). Tout retard au niveau du rendu entraînera une forte pénalité au niveau de la note finale. Tout retard non prévenu annule la soutenance.

Pour les modalités de remise de rapport aux encadrants (date, papier ou numérique), voyez avec eux.

Taille du rapport

Le rapport doit faire entre 15 et 30 pages (à moduler selon qu'une documentation technique soit demandée et attachée, ou non). Les points détaillés dans la suite sont à respecter scrupuleusement.

Il est inutile de grossir la taille de la police, d'augmenter la taille des interlignes ou de multiplier les captures d'écran pour essayer d'arriver à 15 pages. Un rapport vide cela se voit, indépendamment de ces bidouilles-là.

Définitions à donner (ou non)

Il est inutile de passer plusieurs pages à définir des langages ou technologies bien connus (par exemple HTML, Java, PHP, git, Eclipse, MySQL…). Il est en revanche indispensable de définir à quoi correspondent des technologies moins bien connues (par exemple Jenkins, Neo4J, BLE…).

Plagiat (pas de copier-coller)

Vous devez écrire votre rapport vous-même. Dans le cas où vous reprenez du contenu dont vous n'êtes pas auteur cela doit être soigneusement précisé. Dans le cas contraire il s'agit de plagiat et même de fraude. Quand on reprend un texte tel quel, citer la référence à la fin du document ne suffit pas. Il faut mettre ce passage entre guillemets et indiquer très précisément, avant le passage, d'où il provient. Par exemple, voici une bonne manière de faire :

D'après le Trésor de la Langue Française, plagier consiste à emprunter à un ouvrage original, et à son auteur, des éléments, des fragments dont on s'attribue abusivement la paternité en les reproduisant, avec plus ou moins de fidélité, dans une oeuvre que l'on présente comme personnelle.

Notons que paraphraser un texte ne dispense pas de citer très clairement la source comme ci-dessus. Voici également une bonne manière de paraphraser :

D'après le Trésor de la Langue Française le plagiat consiste à reprendre des parties d'une œuvres à son propre en compte, éventuellement en les modifiant légèrement.

Dans le deuxième cas, pour la paraphrase, le fait de réécrire la définition du Trésor de la Langue Française ne me dispense pas de le citer. D'ailleurs c'est bien ce que dit leur définition, il y a plagiat même si les propos sont repris avec plus ou moins de fidélité.

Captures d'écran et code source

Les captures d'écran sur fond noir sont difficilement lisibles (c'est également le cas pour les présentations) et cela gaspille de l'encre. Pensez-donc à passer sur un fond blanc avant de faire des captures (il n'y a évidemment pas d'obligation à en faire). Les captures d'écran ou le code source ne servent pas de décoration du rapport. Dans le texte du rapport il faut faire référence à toute capture ou extrait de code et expliquer le message qu'ils transmettent. Intégrer un code de plusieurs dizaines de lignes dans un rapport est le plus souvent une mauvaise idée. Tout code ajouté au rapport doit être expliqué. Il faut se restreindre à la partie du code qui est intéressante à montrer, expliquer pourqoi elle est intéressante et expliquer le code pour une personne non familière du projet.

Enfin, à la lecture du rapport, votre contribution doit être claire. Une personne n'ayant pas participé au projet doit savoir clairement ce qui a été fait dans le cadre du projet. En particulier lorsque le projet part d'une base existante il faut clairement préciser ce qui pré-existait et les apports du projet.

Divers

Lorsque le code est accessible sur un dépot public, il faut penser à rajouter un lien vers celui-ci dans le rapport. Également, si d'autres documents ont été rédigés dans le cadre du projet (documentation technique, utilisateur, …) pensez à le préciser et à y donner accès (numériquement, il n'est pas nécessaire de les imprimer).


dernière modification : 24/04/2017 à 16:30:12