Conseils

Le carnet de bord

  • Chaque groupe doit maintenir à jour un carnet de bord dans un fichier au format ascii .txt
  • Le chef de projet de chaque groupe se charge de l'envoyez régulièrement par email à son tuteur
  • Le mail doit comporter dans le sujet [PLRICM3] CDB numéro de groupe
  • Votre carnet de bord doit contenir le journal de votre projet tenu au jour le jour.

    Règles absolues :

    • ne JAMAIS effacer quelque chose qui a été écrit précédemment dans ce carnet
    • Dater chaque ajout dans le carnet de bord

  • Le rôle du carnet de bord est multiple :
    • tenir le tuteur au courant de votre progression et de la planification de la suite du travail ;
    • permettre au groupe de faire le point sur l'avancement du projet et la marche à suivre pour respecter les délais
    • en fin de projet, disposer d'une trace de la gestion du projet dans laquelle peuvent être mis en évidence les points délicats ou difficiles du projet.

Quelques précisions pour les fumistes

  • Rappellons que les notes des membres du groupe peuvent varier d'un membre à l'autre.
  • Lors de la soutenance nous demandons à chacun le travail qu'il a effectué. Évidemment nous poserons des questions pour vérifier les affirmations de chacun.

    L'argument consistant à dire "j'ai travaillé sur une partie qui n'a finalement pas été intégré au projet" est irrecevable. Il serait impensable de passer 10 jours à coder quelquechose qui ne sert à rien.
  • Nous nous reservons le droit de demander à chaque membre du groupe (par email) son avis sur le travail des autres membres du groupe. Nous recoupons les informations.
  • La présence au rendez-vous avec le tuteur est aussi prise en compte.
  • L'argument consistant à dire "je travaillais chez moi" n'est pas recevable. On ne fait pas partie d'une équipe si on ne vient pas au réunion.

Présentation de votre projet

Contexte

Une société lance un appel d'offre auprès de développeurs informatiques : elle cherche un sous traitant qui réalisera un simulateur qu'elle pourra étendre avec ses propres composants qu'elle tient à garder secrets car c'est son savoir-faire).

La société vous a communiquée son cahier des charges quelques semaines auparavant, vous laissant le temps de réaliser un prototype. Ce qui vous a permis de vous faire une idée de ce que vous pouvez proposer dans les délais qu'elle vous impose. Elle procède maintenant à la phase de casting.

La présentation de votre projet dure 15 min suivie de 20 min de questions

Cette présentation est un enjeu important. Si vous remportez ce projet, le contrat permet de faire vivre votre société pendant 1 an.

La société choisira son sous-traitant en s'appuyant entre autres sur les critères suivants :
  • la qualité et la pertinence de la présentation,
  • l'imagination et le dynamisme de l'équipe,
  • la cohésion et le sérieux de l'équipe,
  • les compétences techniques :
    • la qualité de l'architecture du logicielle, ses facilités d'extensions,
    • la capacité de l'équipe à anticiper et résoudre les problèmes techniques,
    • la capacité à tenir un planning : répartir le travail et établir un plan d'intégration

      c'est-à-dire :
      • identifier les parties techniquement difficiles ou longues à réaliser,
      • affecter en conséquences le bon nombre de personnes à chaque partie,
      • être capable de modifier cette répartition en fonction des difficultés rencontrées,
      • éviter qu'une tâche cruciale repose sur une seule personne,
      • définir des interfaces claires, précises et adaptables entre les différentes composantes du logiciel afin de faciliter l'intégration.
      • répartir les tâches et structurer le code de manière à pouvoir mener des développements en parallèles et à pouvoir les tester séparement.
      • prévoir des phases de validation avec le client des tâches terminées
      • établir un plan de test et d'intégration qui permet de tester AU PLUS TÔT car
        « coder 2 jours sans pouvoir tester c'est prendre le risque de jeter 2 jours de codage à la poubelle »

Les transparents

Rôle des transparents

  • À la fin de la soutenance nous récuperons les transparents.
  • C'est ce qui nous reste de votre projet, une fois votre présentation terminée.
  • C'est un support pour notre mémoire défaillante. Il nous sert à retrouver votre discours. Comment se souvenir du projet de l'équipe 3 lorsqu'on en a vu 18 défiler ?
  • C'est en se basant sur les tansparents que nous ferons le choix du projet vainqueur une fois le casting terminé.

Quelques conseils sur le contenu des transparents

  • Un transparent doit :
    • être lisible, pas trop chargé,
    • avoir une structure simple et une signalétique claire,
    • résumer les informations essentielles à retenir
    • illustrer le propos de l'orateur
    • ne pas contenir trop de fôtes d'ortaugraffe
  • Le titre doit annoncer de quoi on parle
  • Le discours doit :
    • correspondre au transparent
    • apporter les détails qui ne figurent pas sur le transparent
  • Le présentation doit :
    • comporter un fil conducteur
    • comporter des transitions entre transparents
    • aller à l'essentiel
    • bânir les détails inintéressants ou incompréhensibles
    • être adapté au public (novices ? experts ? les deux ?)
  • Enfin, il faut faire des répétitions :
    • pour respecter la durée imposée
    • n'essayez pas de caser en 15 minutes en parlant vite un discours de 30 minutes, vous assomeriez votre auditoire et feriez mauvaise impression.
    • il faut savoir éliminer le superflu et ne gardez que l'essentiel.

La soutenance du projet

Déroulement des soutenances

Venez avec votre présentation au format .ppt ou .pdf sur une clef USB.
  • remise des rapports en version papier
  • 15 min de présentation
    • Pour l'utilisateur : logiciel, fonctionnalités (sans anticiper sur la démo)
    • Pour le développeur : architecture, principe, hiérarchie des classes, organisation du code, impact des extensions.
    • Pour les enseignants : difficultés rencontrées, répartition des tâches
  • 10 min de démonstration: mettez en valeur votre réalisation en montrant ce qui marche et en passant sous silence ce qui ne fonctionne pas.
  • 20 min de questions individuelles

Contenu des transparents de soutenance

Il ne s'agit pas de faire la même présentation que celle de l'avant projet. La première présentation était destinée à convaincre un industriel de vous confier le contrat de réalisation d'un logiciel. Cette seconde présentation correspond à la livraison du logiciel. Le public sera constitué d'utilisateurs du logiciel et de développeurs qui seront chargé d'intégrer des extensions à votre logiciel. Voici un exemple de ce que nous attendons :
  • Présentation pour l'utilisateur : du logiciel et des fonctionnalités réalisées
  • Présentation pour les futurs développeurs : des aspects techniques (architecture, classes, algorithmique,...)
  • Présentation des difficultés techniques rencontrées et des solutions originales apportés
  • Bilan du projet
    • Planning effectif et répartition du travail durant le projet
    • Décalage par rapport à la proposition de départ et au planning initial
    • auto-critique : si c'etait à refaire, que changerions nous ?
    • Qu'avons nous appris (en dehors des banalités classiques...)
Ceci n'est qu'un exemple de présentation type ; vous êtes libres de parler de ce qui vous semble pertinent. Mais évitez les banalités du genre :
« nous avons beaucoup appris sur le travail en équipe et le gestion de projet, deux points qui nous seront utiles dans notre future carrière »

« ce projet nous a permis de comprendre ce qu'était vraiment le travail d'un ingénieur en informatique »

Démonstration du logiciel

Une démo, ça se prépare. Il faut répéter de manière à impressionner le jury / les clients en leur montrant dans le temps imparti un maximum de choses (qui marchent) et en évitant de mettre en évidence les parties qui ne sont pas tout à fait au point.

Il faut aussi que la démo soit organisée de manière à ce que les clients puissent suivre et comprendre les réactions du logiciel. Il faut donc choisir des exemples qui soient compréhensibles par le jury.

Il faut que la démo présente les fonctionnalités annoncées dans la présentation.

C'est à vous de faire la démo. Il est très mal vu de laisser le client se débrouiller tout seul en 10 min avec un logiciel qu'il ne connait pas.

Les documents à rendre lors de la soutenance

  1. un manuel utilisateur qui fournit
    • une présentation générale du logiciel et des fonctionnalités réalisées
    • comment installer le logiciel
  2. un manuel développeur qui fournit
    • les explications nécessaires à un développeur pour lui permettre d'ajouter de nouvelles fonctionnalités
    • une présentation de l'architecture du logiciel
    • le diagramme des classes
    • le principe de fonctionnement du simulateur
    • une extrait (intéressant, 4-5 pages) du code java du simulateur sur lequel nous jugerons de la qualité de votre codage en examinant les points suivants:
      • Modularité du code
      • Spécification (assertion dans une mesure raisonnable et signatures)
      • Lisibilité (commentaires, noms)
      • Algorithmique (propreté du code dans une mesure raisonnable, choix des structures de données).
Responsable: Michaël PÉRIN